Maintenance status?

[fredbi]

Hello

I am a bit worried about the very low maintenance activity on this wonderful tool that I am using every day, from viper, cobra or standalone.

I know that it essentially just works, but still, the go language and ecosystem all evolve over time and there is clearly some need for a refresh. Pull requests keep piling in, and issues remain unanswered for years. What a pity.

Last time I checked, about 30k open source repositories are directly or indirectly consuming this package, coming second only to the standard library. It is a great contribution to the community, and it shall be preserved in good condition.

As a former maintainer of open source repositories, I know how difficult it can be. Please let me know if you need some help.

Cheers,

Fred

[fredbi]

cc: @therealmitchconnors @sagikazarmark

[sagikazarmark]

I'm not a maintainer of this package. I can probably help out if needed (since it's actually a dependency of Viper), but I have limited resources right now.

I can spend probably a few days to go through open issues and PRs, review/close/merge a few of them, fix some low hanging fruits.

Let me know @therealmitchconnors @spf13

[therealmitchconnors]

My two cents is that we would need some sort of agreed on vision before accepting and rejecting pull requests. @sagikazarmark can you elaborate on how project governance works for Viper or Cobra? I see that viper 2.0 is under development. How did that come about, and what are your objectives there?

That being said, I do believe the go community would be better served with some clarity on what will and won't be merged in pflags, and I think we should work together to develop that.

[sagikazarmark]

My two cents is that we would need some sort of agreed on vision before accepting and rejecting pull requests.

Couldn't agree more! It would probably make sense to go through the PRs and issues and do an initial sweep (close the obvious won't fix/already fixed PRs and issues, merge the obvious, good quality bug fixes, etc). That would reduce the cognitive load and would give us a perspective to what people expect from the library.

But you are absolutely right: any major changes need to be driven by a vision.

Viper is kind of a different beast. The API is fundamentally broken and bloated, yet half the Go ecosystem relies on it. The reason why it takes so long to make meaningful changes is because it all needs to be backward compatible.

Pflag is relatively stable IMO, so once there is a clear vision, it's a question of time and effort to go through the existing requests and keep the maintenance up.

If there is one thing I'd look at is a reduction of the amount of maintained code (either by using a code generator or generics). It's not necessarily the right path, but anything that reduces maintenance burdens is worth considering.

Happy to work with you to figure out a vision/projected roadmap.

Finally, the appropriate XKCD comic:

[fredbi]

@sagikazarmark I am glad you chimed in. I pinged you precisely to bring that kind of feedback (I am also following up your efforts with viper).

@therealmitchconnors
I may help on the issue & PR review. I personnaly pushed some mere linting PR years ago, and most contributors around probably expect minor changes only.

[fredbi]

About roadmap etc, pflag suffers from the same woes IMHO due to the historical lack of generics.

Here is a proposal to extend the functionality with less things to remember about the flags API (but existing stuff would still be supported).

Other than that, I believe that a few things that should be expressed are: (i) how much of this "zero dependency" dogma does this repo want to keep (e.g. tests look really like from the stone age of go), (ii) how do we leverage the extensible aspect of this lib to keep a "contrib space" for extensions

I believe that compatibility is probably the highest value we can bring, so the policy about bringing breaking changes should be clearly stated (hopefully with a no breaking changes promise).

Again happy to help review, comment, rework/rebase old PRs over the next couple of weeks/months.

[cornfeedhobo]

@fredbi Thank you for addressing this head on and opening this issue.

My two cents is that we would need some sort of agreed on vision before accepting and rejecting pull requests

I agree here. I think this question needs to be answered first. Maybe things have changed since when I was attempting to maintain a fork, but last I recall, a number of the open issues resolved down to the core parser, and I don't think they are going to be resolved without consensus on vision and scope. Just my two cents as well.

[fredbi]

Really love that cartoon. Okay so here is a little wording from some thankless guy in Nebraska...

A draft proposal for CONTRIBUTING guidelines.

A draft proposal for a pflag ROADMAP

There is probably a lot to be discussed etc. If we agree on the principle that we should go for something, I may expose these docs as a Pull Request to receive comments, criticism and/or contradiction.

In a nutshell, the opinions expressed in these docs are: compatibility promise (no v2 ever), drop-in replacement for flag promise, prioritize code simplification & test quality over new features, deflect good ideas, breaking stuff etc to some ` spf13/pflag-contrib repo with less stringent constraints.

Please let me know. Anyhow, I volunteer for a more active role here over the next 3-6 months. Difficult to commit over a more extended period.

[fredbi]

@therealmitchconnors I'd like to join as a maintainer so as to be able to:

(i) review and triage pending issues (requires the ability to add tags, and to tag issues)
(ii) review and triage pending PRs (no merge yet, save (iii) below)
(iii) merge the few "revival-only" PRs that I've submitted recently: go test works, linting, CI with github action
(iv) activate github discussions to collect thoughts etc from the community

After this first pass is done, I suppose we can discuss more thoroughly if you have some time.

Hope this helps.

Fred

[therealmitchconnors]

I'm in favor of giving you the ability to triage PRs with tags, but I don't have the ability to grant those privileges, and I'm not sure who does. I am OOO through the 17th, and will try to pull on this thread again at that time.

[fredbi]

Good morning @therealmitchconnors . Do you have any update regarding last month's proposal to assist with the maintenance of pflag?