Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintenance/governance of this project #959

Closed
umarcor opened this issue Sep 11, 2019 · 8 comments
Closed

Maintenance/governance of this project #959

umarcor opened this issue Sep 11, 2019 · 8 comments

Comments

@umarcor
Copy link
Contributor

umarcor commented Sep 11, 2019

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
Copy link
Collaborator

broady commented Sep 11, 2019

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
Copy link
Collaborator

n10v commented Sep 11, 2019

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
Copy link
Collaborator

bep commented Sep 11, 2019

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
Copy link
Owner

spf13 commented Sep 11, 2019 via email

@epk
Copy link

epk commented Sep 15, 2019

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
Copy link
Contributor Author

umarcor commented Sep 16, 2019

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:

@umarcor
Copy link
Contributor Author

umarcor commented Dec 22, 2019

ping....

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

@jharshman
Copy link
Collaborator

@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.

Repository owner locked as resolved and limited conversation to collaborators Dec 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants