Maintenance/governance of this project

[umarcor]

Earlier this year, in March, I gathered multiple pending PRs with minor/easy fixes/enhancements in a branch I named trivial, which was then merged by @eparis. This was almost the only merged contribution since the beginning of the year and until June. @spf13 stepped by, and some long-waiting PRs, such as @jharshman's vgo support, were merged. @spf13 also replied to some other issues, and requested reviews of other users with permissions. During July, @jharshman merged a few fixes, and reviewed some other issues. On August, @BoGeM merged a PR. There have been no contributions to the master branch since then.

During this period, @broady published a tag in May (as requested in #259). This was the first tag since May 2018. In June, @bep published another tag, after merging #822.

There are new minor fixes that are being accumulated in the list of pending PRs. For example, I was about to merge all of these in a new trivial branch: #887 (+1 −0), #896 (+62 −0), #899 (+14 −1), #912 (+5 −3), #929 (+1 −1), #936 (+1 −1), #944 (+1 −1 ), #947 (+3 −6), #948 (+9 −15), #949 (+1 −1), #953 (+104 −9), #954 (+4 −2). However, I feel that such a PR might still be open for several weeks before it is reviewed and merged.

Therefore, I'm opening this issue to ask about the maintenance/governance status of this project. I have identified six users with write permissions (mentioned above), but none of them seems to be actively taking the lead. I understand that other priorities arise; hence I'm not asking any of you to step forward. Nonetheless, it is daunting for potential contributors to see PRs which are already implemented and reviewed be laying around for several months. Furthermore, some users are continuously being called, with no response; which must be annoying at some point. I think we should address this as a community.

Moreover, cobra is imported by more than 12k projects (https://godoc.org/github.com/spf13/cobra?importers) and it has >13k stars. It is a very popular project and lots of users are affected by bugs and/or breaking changes. I understand that we need to be careful with pushing changes too fast. Would it be feasible to have a dev branch where most of the PRs can be merged faster? It would allow to significantly reduce the number of open PRs, so that trickier issues are more visible.

[broady]

To clarify my involvement: I have write access but not a great deal of knowledge about this project, and no time to help/contribute in a significant way.

Thank you for starting this conversation :)

[n10v]

I contributed actively in 2017 but since 2018 I have a part-time JavaScript job while I'm doing my bachelor in university, so unfortunately I don't have any time for cobra and open source generally. Since then I don't know what is happening in go and in cobra inclusively.

Anyway I check Github and notifications every day and see all issues and PRs where I mentioned in cobra. But I don't merge them or make any reviews, because I don't want to risk and merge possible wrong code or make incorrect reviews.

Last time I was really discouraged, how so important project as cobra, that is used by huge projects, could have so poor maintenance. It is really great that we started this conversation, I hope we find some (at least temporary) solution.

[bep]

My involvement in this and many other projects limits itself mostly to issues that hurt/benefit me. That is the time I have to spend.

[spf13]

I (obviously) started Cobra as part of Hugo. It has since taken a life of it's own, being used in most critical cloud infrastructure tools. In my current role as the product and strategy lead of Go, I regret that I don't have a lot of time to code, ironically. When I do have time I often build projects using Cobra and try to keep it up a bit. That's not very often. One of the challenges of so much adoption is a mistake becomes multiplied exponentially. Cobra seems to be working quite well for a lot of projects. I'm very resistant to merge in anything that isn't very clearly an isolated bug fix, for fear of breaking too many projects. However, I do have some thoughts on going forward with this in a way that is better for everyone. A large amount of my time has been working on Go modules. Once fully adopted it dramatically reduces the potential for a break the world incident and there are mechanisms to roll back to earlier releases easily. I'd love to issue a 1.0 release soon. We've already largely committed to no breaking changes because of adoption, we might as well formalize it. Then we can progressively start working through the backlog of PRs and issue patch releases as appropriate. As the replies above show, there's a lot of busy people on this project. I really hope someone will take an interest in it and help. I'd gladly give maintainer access to anyone who wants to help. The key is to tread lightly and step forward slowly. As long as that's followed I think we'd all appreciate help.

…

On Wed, Sep 11, 2019 at 4:11 PM Bjørn Erik Pedersen < ***@***.***> wrote: My involvement in this and many other projects limits itself mostly to issues that hurt/benefit me. That is the time I have to spend. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#959?email_source=notifications&email_token=AABKKZFNROA26LVT4GADXNLQJFGGJA5CNFSM4IVW7D6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6PXYVI#issuecomment-530545749>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABKKZBGXMRHEFTAHLCUCCDQJFGGJANCNFSM4IVW7D6A> .

[epk]

While I don't have experience developing cobra, I have worked on a quite a few projects using cobra.

I'd be interested in keeping this project moving and learning it inside out along the way.

cc: @spf13

[umarcor]

First off, thanks a lot to all of you. I was hesitant to open this issue for several weeks, and I'm glad that it was welcome.

I have (...) not a great deal of knowledge about this project

This is my main fear, indeed. There have been three major contributions since 2016: https://github.com/spf13/cobra/graphs/contributors?from=2016-01-04&to=2019-09-04&type=c. I feel that neither of the three authors (@BoGeM, @jharshman, @babysnakes) had to gain a deep knowledge of the architecture of the tool in order to contribute. At the same time, @spf13 and @eparis knew the architecture four years ago, but the codebase might be hard to recognize for them. IMHO, this is the main issue to address as a community. Can we make an effort to prepare the project for a generational renewal, despite the new generation not being defined yet?

We might imagine an hypothetical new generation contributor to expect/need:

• A (markdown) document with minimal guidelines about the stages that compose cobra. ATM, features are explained to users only. This is totally made up:

* Parse the cli args with pflag.
* Execute all the `init` funcs in no particular order | in a certain order.
* Execute initConfig (i.e. initialize viper).
* Execute rootCmd.Execute
  * First, check if (sub)command is provided and/or positional cli args are accepted
  * Second, check if flags are provided/valid
  * Third...
* Generate shell completion
* Generate docs
* Hooks...
* ...

• Up-to-date linter and static code analysis tools to detect, e.g., dead code.
• Robust test suite, to ensure backwards compatibility.
• Instructions to run linter and tests without setting up a CI service.
• Any explicit branching/release model.

In my current role as the product and strategy lead of Go, I regret that I
don't have a lot of time to code, ironically.

Note that this is not a criticism but a humble and sincere request: it is perfectly ok if you can't code, because there are many contributors willing to submit PRs; what we do need is a product and strategy leader for cobra who can take decisions when potentially breaking changes are proposed.

For example, in #876 golangci-lint is used. As a result of using io.StringWriter, support for golang 1.10.x and 1.11.x is broken/deprecated. As a leader of Go, you are in a privileged position to just tell us what you/we want:

• Use build tags keep/maintain two sets of sources in the same branch (see #853). This is required until golang 1.xx, at least.
• Keep current sources in a branch named v1, and work on master for golang >=1.12.
• Keep current sources in a branch named v1, apply backwards compatible changes in master, and create v2 for golang >=1.12.

I'm very resistant to merge in anything that isn't very clearly an isolated
bug fix, for fear of breaking too many projects.

As far as I acknowledge and share this, I find that the vast majority of PRs do not introduce any breaking change. Conversely, most of them are either bug fixes or enhancements for features that were implemented partially and never completed. Cobra is doing very well, but it's getting old fast. Let's take care before it dies!

I'd love to issue a 1.0 release soon. We've already
largely committed to no breaking changes because of adoption, we might as
well formalize it. Then we can progressively start working through the
backlog of PRs and issue patch releases as appropriate.

Can we all do a little effort to label all the issues before releasing 1.0? On the one hand, I feel that 25-50% of the issues should be merged before 1.0 (see e.g. the 12 10 9 8 5 refs above). On the other hand, some issues such as (#841, #880, #937) can be merged before 1.0 because i) partial implementations are completed and ii) are backwards compatible. I'm ok with releasing 1.0 and 1.1 one after the other too.

We can use 3-4 milestones (1.0, 1.1, 2.0 and backlog):

• 1.0: to be merged before 1.0.
• 1.1: to be merged after 1.0 but without any explicit breaking change.
• 2.0: breaking changes, not to be addressed before 2.0.
• backlog: to be decided. Might contain opinionated implementations, very specific/niche eatures, etc.

I believe you can ask contributors for help here. E.g., pin a new issue as an announcement that you/we are going to sort issues towards releasing 1.0. Unfortunately, it is not possible for any user to label their PRs. However:

• You can assign triage and maintain roles: https://github.blog/changelog/2019-05-23-triage-and-maintain-roles-beta/
• Someone could contribute a GitHub Action that would check the content of the first message in a PR and apply labels.
• Users can just reply to their PR suggesting a label, so maintainers don't need to read long dicussions.

[umarcor]

ping....

Milestone 1.0.0, scheduled for two days ago, is at 47%.

[jharshman]

@umarcor, as you know it is the holiday season. Some things come up and as such other items get adjusted priority. Although we did not hit the milestone by the estimated date, we will continue toward releasing a 1.0.0 of Cobra early in the New Year. Thank you for your patience and understanding.