Expand my permissions a bit

[tomasaschan]

@spf13 since #385 (comment) I think I have proven my worth as a maintainer of this library, and would like to kindly ask for some more permissions on the project here on Github. In particular, I think it would be useful if I had access to

• Modify the repo setup to e.g. enable features like discussions
• Manage access to the repo, in order to promote other active contributors to maintainers if they so wish
• Manage milestones etc in order to triage and prioritize issues that come in on the tracker (edit: apparently I already can do this - I just have to do it through the web UI rather than the app...)

There might be other things too, but in essence I'd like to be promoted from my current state of "maintainer helping out" to "maintainer co-owning the project", if that's OK with you.

[ayanamist]

Then you can make more break changes in patch releases?

[tomasaschan]

...and fix them in less than 12 hours despite being on parental leave and juggling a restless one-year-old and a three-year-old with a stomach bug. But sure, make this about myself, rather than about not enough people helping our with this project (and @spf13 apparently being the only one who can grant access for others to pitch in, at the moment).

[thaJeztah]

@ayanamist nobody forces you to use the latest version; it's up to you to verify dependencies when updating. Things may break in any update; and this one was corrected after it was reported .

[spf13]

@tomasaschan I'm happy to give you more access. Unfortunately, it's my understanding that Github doesn't provide this ability. For some reason Github treats organizations and individual accounts significantly differently and this is my personal account. I'll talk to Github about what options we have. I don't want to change the url because it's what all the imports use across hundreds of thousands of repos. Maybe the right answer is to make spf13 an organization.. which feels really odd because I'm spf13 but might be the right answer.

If anyone can shed light on this happy to have help.

[jpmcb]

pflag, cobra, and viper are packages used, at least by proxy, by every single fortune 500 company and every single cloud. They make up the backbone of some of the most important modern technology infrastructures today (Kubernetes, Docker, etc.).

But we are also just a rag-tag group of open source enthusiasts who freely give up our time and energy to ensure these open and free packages stay stable.

I applaud @tomasaschan for his dedication to this project. And I commend him for sticking with it when things happen: let us not forget the many times that I've broken Cobra!!!! Otherwise, these projects rot and pile up with stale security issues.

@ayanamist - if you'd like to help make this package stay stable, contributions are always welcome.

[jpmcb]

@spf13 - happy to join any conversation with GitHub: I know that when you "Transfer" a repository, GitHub sets up all the redirects and, since go get / go mod are git based, it should just work.

So, if we moved spf13/cobra or something into our-org/cobra, GitHub would setup redirects from github.com/spf13/cobra to github.com/our-org/cobra and go get -u github.com/spf13/cobra would still just work as expected.

---

Small proof of concept:

1. Made github.com/jpmcb/chizap
2. Transfered it to github.com/agent-api/chizap: https://github.com/agent-api/chizap
3. Original URI still works:

❯ go get github.com/jpmcb/chizap
go: downloading github.com/jpmcb/chizap v0.0.0-20250903145357-2d6032ec3111
go: added github.com/go-chi/chi/v5 v5.2.3
go: added github.com/jpmcb/chizap v0.0.0-20250903145357-2d6032ec3111
go: added go.uber.org/multierr v1.10.0
go: added go.uber.org/zap v1.27.0

[tomasaschan]

This might also be an opportunity to explore services like https://gopkg.in to abstract away the storage location of the source code from the usage in downstream projects. That won't help current usage, but could help future proofing if we allow them to coexist for long enough for the main users (primarily Cobra) to migrate.

[ayanamist]

@jpmcb The related commit is five years ago and recently merged. I don't know how to contribute to avoid such accidents.

[tomasaschan]

@ayanamist If you know of a way to implement a check that runs on merge to master and verifies that there are no changes which break against the latest released version, a way to contribute would have been to submit a PR to implement that here - or even just open an issue with some info about how to do it, so someone else could implement.

And it's not too late to be useful! It happened once, so it can happen again - but if there's a way to implement guardrails against it, I'm all ears.

If you don't know how to do that, then maybe have a little empathy with the fact that the rest of us also don't?

[thaJeztah]

Hey 👋 @spf13 good to see you!

Good questions; not sure if I ever converted an account to an org; I think I did once, but that was for an empty org, so nothing to really lose there, and I don't know if changing a namespace to an org means "losing your personal account".

Technically, moving the pflag (and Cobra?) repositories to a separate org could still work, but could be somewhat disruptive;

option 1: transfer the repositories to a new org

GitHub automatically adds redirects when moving repositories, which means that existing releases can still be used under their existing name (both when using the go module proxy, and "direct")

There's one important caveat; you must NEVER create a new fork of the repositories under your name, as those will now stop the redirects (effectively "hijacking" the existing modules); I'm not sure if GitHub has any protection against this nowadays, but I know this has been used by bad actors in the past. Admitted; go modules sum.db will provide protection, but not ideal still.

Once migrated, the projects can decide to rename the module; this doesn't have to be done immediately (some projects (cough docker), took some years before doing so 🙈)

If the redirects are kept functional, both "old" and "new" names of the modules can be in the same repository; new tags can use the new import path and module name; old tags use the old name. But it will require the ecosystem to update import paths at some point. It's not unprecedented, so maybe it's an "OK" hurdle to take.

To help the migration, the project can do a "transitional" release; create a release of the modules under the old name (make sure there's no overlap in versions!) that is implemented using the new module by creating aliases and alias wrappers for all types and functions; i.e., the pflag package for that release would look something like;

package pflag

import "github.com/new-org/pflag"

// A FlagSet represents a set of defined flags.
type FlagSet = pflag.FlagSet

func UnquoteUsage(flag *Flag) (name string, usage string) {
    return pflag.UnquoteUsage(flag)
}

// etc..

Such a transitional release would work as long as the projects are correctly using SemVer, and with the transitional release (indirect) dependencies can be migrated to the new module even if they haven't been updated.

Big advantage of transferring the repository is that all history, including tickets and pull requests remain in one place.

option 2: keep the old, blessed fork in a new org

In this case, the projects start "fresh" in a new org, forked from the current repository. This is more disruptive at start, and means that tickets and pull requests are not transferred (but it's possible to manually "migrate" pending PR patches to the new repository).

In this scenario, we should probably mark the old repositories frozen, but could decide to keep an overlap; it's possible to do a "transitional" release as described in "option 1" to makes sure that (indirect) dependencies that have not yet transitioned to the new module still get updates.

Keeping the old repository (and archiving it at some point) prevents accidentally breaking the redirects (as it's intentionally forked), but having history of tickets and pull requests in separate locations is definitely a big downside.

[thaJeztah]

@tomasaschan For determining SemVer versioning; I recall the Go team had some (experimental?) tools in golang.org/x/tools golang.org/x/exp

ISTR there was another project providing something similar but I forgot which one 😆

I have not really used these modules, but think I tried them once a long time ago;

https://pkg.go.dev/golang.org/x/exp/cmd/apidiff

https://pkg.go.dev/golang.org/x/exp/cmd/gorelease

[ayanamist]

@ayanamist If you know of a way to implement a check that runs on merge to master and verifies that there are no changes which break against the latest released version, a way to contribute would have been to submit a PR to implement that here - or even just open an issue with some info about how to do it, so someone else could implement.

And it's not too late to be useful! It happened once, so it can happen again - but if there's a way to implement guardrails against it, I'm all ears.

If you don't know how to do that, then maybe have a little empathy with the fact that the rest of us also don't?

I dont quite understand what you are saying. Change a public export method name are always breaking something, it's quite obvious when review by human eyes. Are you saying you merge the code without review them only depend on CI check?

[tomasaschan]

I'm trying to say two, or maybe three things:

First off, code reviews on PRs will never be, and should not be, a sufficient mechanism for quality control. A human reviewer will miss things occasionally, and so in cases where a single failure is considered unacceptable it simply cannot be relied on. PRs are, IMO primarily a mechanism for contributors without direct write access to a code base to propose and discuss changes, and a space for contributors with access to share ideas and context amongst themselves to ensure that the why of a change is clearly understood. They can also be used as collaborative spaces for iterating on design aspects etc. But if something is important, there should be an automated check that ensures it is kept working.
The change was merged on July 17, but not released until August 31. That's plenty of time for me discover the error and fix it, if there's something there to tell me about it, such as an automated API compatibility check, an integration test suite, or even someone doing some manual testing with latest master and reporting any issues. None of this was in place, which is what let the bug slip through all the way to a released version. Blaming the reviewer for a bug that slipped through is looking in the wrong place for where the system failed.

Second, since you seemingly care a lot about this library, I'm trying to invite you to contribute, and highlighting, in particular, some ways to do that which address the problems you seem to care about. You're still welcome to do so, but since you seem pretty uninterested to actually pitch in, I won't mention it again.

Thirdly (but not the least important...), I'm asking you to reevaluate your choice of tone. You came into this thread, which is completely unrelated to the bug that was shipped, with an attack on my suitability as a maintainer. You posted that comment after a fix was already released (which happened less that 12 hours after the faulty release, and even less after the issue was posted notifying us of the problem). Maybe dial down the snark a few notches?