Placeholder repo migrating maintenance

[mfridman]

See dgrijalva/jwt-go#462 for a lengthier discussion and background.

For brevity, there is/was an attempt to migrate to the gors organization, issues here, but unfortunately there was no response on GitHub issue or Slack #gofrs channel.

---

Hopefully other can chip in, but afaics the goal of this org/repo:

1. patch any outstanding security issues
2. add module support
3. maintain the existing jwt-go API in its current form
4. setup GitHub Actions as CI for existing tests
5. have a few independent maintainers to spread the load and trust of maintenance with the ultimate goal of the Go community having access to a stable JWT package.

The intention is to support the package in its current form without any major re-write or refactor.

I still hope one day the Go standard library or /x will add JWT support and backing from the Go team.

---

If there is agreement we can setup independent GitHub issues to tackle the above and address these in particular.

dgrijalva/jwt-go#428
dgrijalva/jwt-go#463

cc @ripienaar @Waterdrips @lggomez

[mfridman]

Another thing to consider is what access to setup on the org/repo. I also do not want to be the sole "admin" and this should be spread among a few people. Based on interactions on various oss projects and blog posts and talks I hope the lot is trustworthy and there is no malicious intent, but this is hard in open-source. Any suggestions welcome.

[Waterdrips]

I'd guess a couple of admins and the rest as org members. repos needing at least 1 approving review before merge as well as CI passing?

Do we know what a migration to this org would look like? Are we askin @dgrijalva to transfer ownership?
I'd guess this would auto-migrate anyone using the dgrijalva/jwt-go import path due to github's redirect? Is that what we want?
Alternatively we can bring all the commits into a new repo here which is more work, and ask @dgrijalva to archive the repo with a notice in the README?

[oxisto]

I'd guess a couple of admins and the rest as org members. repos needing at least 1 approving review before merge as well as CI passing?

Do we know what a migration to this org would look like? Are we askin @dgrijalva to transfer ownership?
I'd guess this would auto-migrate anyone using the dgrijalva/jwt-go import path due to github's redirect? Is that what we want?

The GH redirect works quite good, I just tested it using a small internal test repo (https://github.com/oxisto/go-httputil). I can still download old versions from the old import path, also the pkg.go.dev site still works (https://pkg.go.dev/github.com/oxisto/go-httputil). It links to the old GitHub repo page, but that is redirected to the new one.

I then change the path in the go.modon the new repo and did a 'v2' release on the transferred repo. This one of course only shows up on the new https://pkg.go.dev/github.com/aybaze/go-httputil/v2 site.

The only pain in this case is the switch from "plain" to /v2 module syntax.

Alternatively we can bring all the commits into a new repo here which is more work, and ask @dgrijalva to archive the repo with a notice in the README?

[lggomez]

The gerrit model for example works by requiring more than one approval so something like that could work (ceremoniously since github doesn't have flows like that yet). I adher to @mfridman's sentiment, this can't (or shouldn't be at least) be a centralized thing (in the sense of just one or two people). I, for instance, could check PRs and the sort but if my availability is not enough to respond in due time we don't want the repo to go stale again, so another member can hop in and continue the work

The GH redirect works quite good, I just tested it using a small internal test repo (https://github.com/oxisto/go-httputil). I can still download old versions from the old import path, also the pkg.go.dev site still works (https://pkg.go.dev/github.com/oxisto/go-httputil). It links to the old GitHub repo page, but that is redirected to the new one.

I then change the path in the go.modon the new repo and did a 'v2' release on the transferred repo. This one of course only shows up on the new https://pkg.go.dev/github.com/aybaze/go-httputil/v2 site.

The only pain in this case is the switch from "plain" to /v2 module syntax.

Those are good options to know, I suspected that tweaking the mod files was going to be necessary but the github redirect is a feature I was not aware of

[lggomez]

I'd guess a couple of admins and the rest as org members. repos needing at least 1 approving review before merge as well as CI passing?

The org should also be public (I guess it is private right now because it is brand new, this is just a reminder)

Do we know what a migration to this org would look like? Are we askin @dgrijalva to transfer ownership?
I'd guess this would auto-migrate anyone using the dgrijalva/jwt-go import path due to github's redirect? Is that what we want?
Alternatively we can bring all the commits into a new repo here which is more work, and ask @dgrijalva to archive the repo with a notice in the README?

Both options need this blessing/action so I guess it will boil down to whichever he prefers

[oxisto]

The gerrit model for example works by requiring more than one approval so something like that could work (ceremoniously since github doesn't have flows like that yet). I adher to @mfridman's sentiment, this can't (or shouldn't be at least) be a centralized thing (in the sense of just one or two people). I, for instance, could check PRs and the sort but if my availability is not enough to respond in due time we don't want the repo to go stale again, so another member can hop in and continue the work

You can do that with the (new) branch protection settings now as well. It has quite extensive rules on how many reviews, who can dismiss reviews, also define a group people who's review is mandatory (through setting them as a code owner) etc. Code owners can also be set to different files, directories. The world is your oyster.

So this is definitely something one should agree on beforehand.

[mfridman]

I'd guess a couple of admins and the rest as org members. repos needing at least 1 approving review before merge as well as CI passing?

Added the 4 folks mentioned in that original issue as org members, and it looks like @oxisto has interest to help here so maybe adding him as a maintainer for this repo?

Do we know what a migration to this org would look like? Are we askin @dgrijalva to transfer ownership?
I'd guess this would auto-migrate anyone using the dgrijalva/jwt-go import path due to github's redirect? Is that what we want?
Alternatively we can bring all the commits into a new repo here which is more work, and ask @dgrijalva to archive the repo with a notice in the README?

I quite like GitHub redirects, but I'm a bit conflicted because if users are importing github.com/dgrijalva/jwt-go then that is the repo (and source code) they are expecting.

What do others think?

Also this will depend on what original maintainer prefers. I'll ping dgrijalva/jwt-go#462 to see if there is a preference.

---

Maybe we can open another ticket to figure out how to add module support? Since there might be a new import path via s/'dgrijalva/jwt-go'/'golang-jwt/jwt', one alternative is to drop the existing version and tag this repo (and module) as v1.0.0 .. for users this would be a simple change in import paths?

[mfridman]

I'd guess a couple of admins and the rest as org members. repos needing at least 1 approving review before merge as well as CI passing?

The org should also be public (I guess it is private right now because it is brand new, this is just a reminder)

@lggomez Could you elaborate on this point? Maybe I missed something..

afaik https://github.com/golang-jwt is a public org, but its up to each "org member" to publicize whether they are part of the org or not.

[lggomez]

I just wasn't seeing the organization members before, so I assumed it was private. Sorry if it was not the case

[oxisto]

I'd guess a couple of admins and the rest as org members. repos needing at least 1 approving review before merge as well as CI passing?

Added the 4 folks mentioned in that original issue as org members, and it looks like @oxisto has interest to help here so maybe adding him as a maintainer for this repo?

Ah, yes! Sorry for the delayed answer. Feel free to add me as a maintainer directly to the repo, looking forward to help!

[oxisto]

The gerrit model for example works by requiring more than one approval so something like that could work (ceremoniously since github doesn't have flows like that yet). I adher to @mfridman's sentiment, this can't (or shouldn't be at least) be a centralized thing (in the sense of just one or two people). I, for instance, could check PRs and the sort but if my availability is not enough to respond in due time we don't want the repo to go stale again, so another member can hop in and continue the work

You can do that with the (new) branch protection settings now as well. It has quite extensive rules on how many reviews, who can dismiss reviews, also define a group people who's review is mandatory (through setting them as a code owner) etc. Code owners can also be set to different files, directories. The world is your oyster.

So this is definitely something one should agree on beforehand.

@mfridman Do you want me to set the branch protection rules so that 2 reviewers are needed? But it seems I am missing the permissions for that. I can set the general merge options, but not the branch protection rules.

[mfridman]

@oxisto maybe 1 reviewer is sufficient, but I don't have a strong opinion. Let's see if @Waterdrips @lggomez @ripienaar have thoughts around this ..

Also, is the repo sufficiently setup as a "community" project where access is spread across multiple people and the main concerns have been addressed?

Apologies for the noise as we get things figured out.

[ripienaar]

1 required, but with a policy of 2 being the norm - but if we're busy and only 1 can pay attention I think that should be fine.

[oxisto]

I think we can close this? Or do we have anything left over on our bucket list? Does everyone of the "original" four (@ripienaar, @lggomez, @mfridman, @Waterdrips) have all the access they need? As far as I can see, I am not part of the org, but have direct maintainer access to the repo - which is also fine. You can also add me to the org if that makes things more consistent, either way is fine by me.

Some kind of message on the original repo would be nice, but that is up to @dgrijalva.

Apart from that I think we did all we can do on our end?

Update: Would make sense to add @dgrijalva as maintainer to the org / repo as well? In case he decides to come back. Would be a nice gesture I think.

[mfridman]

I was hoping there would be some conclusion to dgrijalva/jwt-go#462

It's still up in the air whether @dgrijalva wants this project to:

1. continue residing under his account: dgrijalva/jwt-go with external maintainers at the repo level
2. maintained via this community effort under golang-jwt/jwt

IMO they are mutually exclusive. Otherwise, we get fragmentation within the ecosystem, and this is never good.

[mfridman]

Bump. Keeping an eye on dgrijalva/jwt-go#429 stemmed from this comment dgrijalva/jwt-go#462 (comment).

Once this gets merged and that issue is resolved I'll close this ticket with a status update.

[mfridman]

The upstream security fix was merged dgrijalva/jwt-go#429 and the repo has an updated README.

Ideally @dgrijalva would also archive (sunset) the repository, to avoid folks continuing to open issues / PRs against it .. but that's totally his choice.

Going to close this issue. Please feel free to comment on this thread if anything is outstanding.