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?

[cornfeedhobo]

@fredbi if you're interested in forking a drop in replacement, shoot me any email. You can pull it from any of my commits.

[josegonzalez]

Could/should we just create a new org - go-pflag?, since pflag is already taken? - and then just start there? It seems @spf13 has taken a leave of absence from at least this repo (and maybe others), and there doesn't seem to be anyone else capable of merging or releasing this repo, so the next best thing would just be to start an org and go from there?

[fredbi]

@cornfeedhobo @josegonzalez yes, you're right. After months of waiting for this situation to be unblocked, I came to the conclusion that there is no other resolution to this issue.

Ok so let's go for go-pflag. I hope that the guys at spf13/viper (cc: @sagikazarmark) and koanf (cc: @jkroepke) are willing to switch over so we can start this new story.

[jkroepke]

I'm just a user of koanf. You could poke the author here (knadh/koanf#253), if you want. I personally would recommend to switch after some months. Lets have an look if the new project gets maintained well.

I recently switch to stdlib flags, it works for me, too.

[fredbi]

I'm just a user of koanf. You could poke the author here (knadh/koanf#253), if you want. I personally would recommend to switch after some months. Lets have an look if the new project gets maintained well.

I recently switch to stdlib flags, it works for me, too.

Yeah sure. Will do.

[sagikazarmark]

While I’m not against forking per se, I’d suggest thinking it through thoroughly.

It’s gonna have a huge impact on the ecosystem. Not to mention it’s a huge burden to take over a popular project like this.

Make sure you are prepared to allocate the time and effort for years to come.

[fredbi]

While I’m not against forking per se, I’d suggest thinking it through thoroughly.

It’s gonna have a huge impact on the ecosystem. Not to mention it’s a huge burden to take over a popular project like this.

Make sure you are prepared to allocate the time and effort for years to come.

@sagikazarmark my initial intend was just the “revive” the existing project, with a limited ambition and zero impact for dependent libraries. However it seems that just joining the maintainers group is impossible (not in 6 months at least). So what other choice is available?

[sagikazarmark]

6 months is not a long time in OSS, in my experience. Also (and I don't mean any offense), becoming a maintainer doesn't generally happen overnight, especially not without a prior reputation with a project.

In my experience, it's much easier to achieve the blessed fork status when maintainers are in agreement. It definitely makes the transition easier for the community. Otherwise, it's a lot more confusing.

So what other choice is available?

Have you tried approaching any of the existing maintainers outside of this issue? It's generally NOT considered to be the best of options, but when all else fails, this is still there.

[josegonzalez]

I've reached out via twitter, maybe @spf13 will be able to respond.

[sagikazarmark]

I also reached out to Steve via email.

[spf13]

Thanks for tagging me in this. I'm happy to grant access to anyone who has the desire to improve this library (while recognizing that it's a core dependency for much of the Go ecosystem so tread with care).

Should I start with making @fredbi a maintainer?

[spf13]

I think the roadmap @fredbi proposed looks quite good. Full support of this direction.

[fredbi]

Thanks for tagging me in this. I'm happy to grant access to anyone who has the desire to improve this library (while recognizing that it's a core dependency for much of the Go ecosystem so tread with care).

Should I start with making @fredbi a maintainer?

@spf13 please go ahead steve!

I’ve left a “manifesto” pull request (link is above) so rest reassured we don’t want to disrupt the ecosystem.

[spf13]

I've just added @fredbi and @sagikazarmark as maintainers to this project. You both should now have access to invite others as you see fit. Thanks for taking an interest in this!

[josegonzalez]

Thank you @spf13 for chiming in and letting folks into the project.

Given that we have a path forward, I think we can probably close this ticket and follow up on the manifesto PR :)

[cornfeedhobo]

@fredbi Catching up and I see you've been able to get some progress here. Great work. Unfortunately I don't have enough free time at the moment to offer, but looking forward to seeing what comes.