[Openid-specs-ab] Migrating source control to github?

Sun Jan 29 06:11:39 UTC 2023

I forgot to post, but, confirmed that SSE WG migrated to a free GitHub account without losing any history.

Best,
Kristina
________________________________
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on behalf of Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net>
Sent: Saturday, January 28, 2023 9:50:56 PM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: nat <nat at nat.consulting>
Subject: Re: [Openid-specs-ab] Migrating source control to github?

As I stated before, migration is a significant decision and requires a well-thought-out plan.
Also, if we are going to migrate, we also have to evaluate other options including pricing and it should not be taken lightly.
We did evaluate various options at the board level when we shifted the dev branch of the repo from SVN to BitBucket.
I believe we still use SVN for significant commit.
Also note that at the time, it was easier as we did not issue a tracker and we did all the business on the mailing list, which we still use as well.
(Issue tracking and linking it to the fixes were the main aim of the introduction of the tool.)

BTW, I am not sure if GitHub will be free for us. That was one of the considerations at the time of the introduction of BtiBucket.
Their "non-profit" means 503(c)3 but we are 503(c)6 so we were not eligible for the free version.

For some of the things you mentioned, Kristina, there actually a way to make it better without migration.

  *   To link the issues and comments, you should be using that tag feature in git messages. Putting -m "fixes #1254, #1357" etc. does link the commit to the issue.
  *   Instead of using a custom "tag" (I believe you really meant "labels" in github) in issue title, you could use the Workflow status. On the free version, it is not customizable but if you use that, your workflow will be much better than putting the label into the title. You can easily sort, and you can create filters. You definitely do not need to go through pages if you do that.

Oh, also
If we want someone to do a PR, we message MikeL so that he can grant admin permission, which is more that we want to grant and this has led to issues. one author is also still struggling with getting these permissions set up.
that's definitely what you should be doing. It should be write access instead and any Admin should be able to give it.
I got so worried that I just check the repo access permission but nobody but John, Mike and I had the admin access.

So, who is struggling? Certainly, all the chairs can add the person. (I do not think Mike L. can do it though and that might be the reason he is not getting added.)

2023年1月27日(金) 19:46 Joseph Heenan via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>:
Hi Kristina

For info, my understanding is the spec repositories are all using the bitbucket free plan - so leaving the repositories accessible on bitbucket is definitely one route to keeping things like comments on historical PRs available to access.

As someone said, it’s a bit “out of the frying pan, into the fire” when moving from one free code collaboration tool to another, but there’s not much alternative unless we self-host, which also has disadvantages. Probably there are small sensible decisions we should make such that any future migration off GitHub is easier, e.g. if we use GitHub pages, we should set it up on an openid owned domain name instead of a GitHub one.

The zoom migration was an order of magnitude or more easier than the move to GitHub will be :-) As Nat said, a foundation-wide move to GitHub needs a non-trivial amount of time from someone pretty technical to do all the donkey work.

I’m strongly in favour of moving off bitbucket, for the reasons you and Mike have said.

Thanks

Joseph

On 26 Jan 2023, at 06:00, Kristina Yasuda via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:

Thank you Nat and Aaron.

tl;dr Using Bitbucket and not Github has been significantly slowing down the work on the specifications, so I don't believe there is an option not to migrate. And I believe we can do so while preserving history for accountability and transparency without too much effort.

First, let me name a few limitations of Bitbucket that I have faced myself or have heard from other people:

  *   there is not suggestion feature, the PR author cannot accept minor editorial suggestions with one click
  *   There is no automatic linking between PRs and Issues. For example PR authors have to manually put an issue number in the PR and vice versa - this has led to more time spent on issue triaging
  *   There is no tag feature. To overcome this, when triaging issues, I have started to manually put [has-PR], [needs-PR], [pending-close] etc in the issue title - it takes a lot of time.
  *   Sorting of the issues is pretty bad. For example, sorting by author does not really work. I also can’t sort using the tag-alternatives I mentioned above so I have to click through 4-5 pages of issues to find the [needs-PR] issue that I need to work on.
  *   Tagging people is very random and usually does not work. I start typing a name after “@“ but it rarely comes up. So I have to message a person individually.
  *   There is no PR re-review feature. Again, after making suggested changes, I need to ping a person to re-review.
  *   Access permissions is hard to use: we can’t set up so that only chairs and editors can merge/close issues, but anyone can do a PR. If we want someone to do a PR, we message MikeL so that he can grant admin permission, which is more that we want to grant and this has led to issues. one author is also still struggling with getting these permissions set up..
  *   when asking to review a PR, I have multiple times have gotten a feedback that “Can’t because not used to Bitbucket”
  *   Etc.

We need to move to GitHub. (We could invest effort in making Bitbucket experience better, but I can’t see a way to overcome all of the limitations I listed above)

Having said that I also understand the importance of preserving history from accountability/ transparency perspective and agree that it is important. and I think we can do it without a multi-months investigation. Just to give few potential ideas:

  *    I did a quick search and found that Bitbucket allows to export history. We could do it and host it using the tooling we like (does not have to be cloud-based) - it would not cost a fortune.
  *   We can start using GitHub for free and keep paying Bitbucket to preserve the history. (I don’t know if current Bitbucket is paid or not). Free GitHub account is sufficient. IETF OAuth WG uses free version and it has been sufficient.
  *   (Also confirming with Tim if SSE lost all their history when migrating.)
  *   (I also wonder why Goto meeting to zoom migration was prioritized over Bitbucket to GitHub migration)

Best,
Kristina

________________________________
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>> on behalf of Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Sent: Wednesday, January 25, 2023 9:00 PM
To: Aaron Parecki <aaron at parecki.com<mailto:aaron at parecki.com>>
Cc: nat <nat at nat.consulting>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Subject: Re: [Openid-specs-ab] Migrating source control to github?

Thanks for the pointer!

At the same time, it is a curse to use cloud-provided tools rather than hosting your own open-source-based one, is that there could be some limitations on the exporting capability. What I am pointing out is that they need to be researched, planned, and executed professionally, just like any other migration project, including budgeting.
As it involves cost, it also needs to demonstrate its merits as well together with risks and other negative factors as well.

2023年1月26日(木) 13:45 Aaron Parecki <aaron at parecki.com<mailto:aaron at parecki.com>>:
While I don't know the full extent of what it takes to do this, it is definitely possible to migrate old issues and their history. The IETF migrated from their own Trac instance over to GitHub a while back, including porting all the old issues over. For example:

https://github.com/ietf-tools/datatracker/issues/1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-tools%2Fdatatracker%2Fissues%2F1&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb54c63244c2d44fecb9508db01bce391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638105683162407570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ceGewvYylY2UIktHgPMxSP1ZYfx%2FO1ebIlgnulU7mr4%3D&reserved=0>

Note the date of the issue is 2007, and includes a comment about when the migration happened. All the comments and history of the Trac issue migrated to the GitHub thread as well.

I believe this provides sufficient context for the history of the issues. And arguably moving from one silo (bitbucket) to another (github) is less problematic than moving from a self-hosted tool that could have maintained the permalinks anyway.

Aaron

On Wed, Jan 25, 2023 at 8:30 PM Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:
I am strongly opposed to the migration unless we can move the entire history (including timestamps) of the issues and PR linkages etc. We have been painstakingly doing that.
It is not just a matter of whether we have finished working on a work etc. It is a transparency and accountability issue for the entire foundation.

When we moved from Mercurial to Git, we made sure that it was the case. At the time, we also evaluated if it was possible to move to GitHub, but the answer was negative. Given that the migration was done like 5 years ago, the situation may have changed, but unless that is made sure, we cannot migrate.
The last migration did not impact the Foundation's budget because NRI took the cost of researching it and the migration of it, but that was not trivial.

Also,
> 2 - Github orgs would allow for a connect or OpenID parent with individual repos for the various specs similar to other specification efforts using github (more focused issue
is not a good reason as it is the same in BitBucket.

Best,

Nat Sakimura

2023年1月20日(金) 0:38 Torsten Lodderstedt via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>:
+1 to migrating after we published the Implementers Drafts of OID4VC

On Jan. 11 2023, at 6:54 pm, Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:

As discussed during a working group call (I think in December), there’s an appetite for moving *all* Connect specs to the GitHub repository github.com/openid/connect<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgithub.com%2Fopenid%2Fconnect&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb54c63244c2d44fecb9508db01bce391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638105683162407570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=u4niG0MsgfDWqrqdIz5TQNSWPsCz1fpmyx9VnkZAyKU%3D&reserved=0> at the same time.  We should move them all because then we maintain the benefit of having a single issue tracker for the working group.  If we had to use different issue trackers for different specs, that would be an ongoing source of confusion.  It would also make it more difficult to chair calls, since we’d have to triage issues and PRs across multiple repositories.

When we move, issues will all migrate.  PRs will not migrate.  Therefore, we should be mindful about when to migrate so as to minimize the number of open PRs.  The consensus when we last discussed this is that the right time to migrate is after we publish proposed Implementer’s Drafts for the OpenID4VC specs.  (The OpenID Connect Federation editors can also try to ensure that most/all of the Federation PRs are merged at the same time.)

So if any of you need more motivations to review OpenID4VC issues and PRs and get us to proposed Implementer’s Drafts, take into account that you doing so will accelerate our migration to GitHub. 😊  Let’s promptly advance the OpenID4VC specs!

                                                       -- Mike

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>> On Behalf Of Joseph Heenan via Openid-specs-ab
Sent: Wednesday, January 11, 2023 2:36 AM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Cc: Joseph Heenan <joseph at authlete.com<mailto:joseph at authlete.com>>
Subject: Re: [Openid-specs-ab] Migrating source control to github?

Hi Jeremie

I think I’d be in favour of this.

There’s precedent for this, the OIDF shared signals and events group already moved to GitHub:

https://github.com/openid/sse<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenid%2Fsse&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb54c63244c2d44fecb9508db01bce391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638105683162407570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=VzvRSDqyYOhYu9txmDB0k15KjZPPLMKYHRp089x%2BwPE%3D&reserved=0>

I think whether each WG has one repo per WG (as currently on bitbucket and as SSE currently do on GitHub) or one per spec (as you are I think suggesting) is a slightly more nuanced discussion.

Thanks

Joseph

On 11 Jan 2023, at 00:59, Jeremie Miller via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:

I wanted to put out a feeler to this group on interest in migrating from bitbucket to github for the OpenID4VC family of specs.

The reason I'm only suggesting migrating a subset of the larger connect repository is two-fold:
1 - They're younger specs and the team managing them right now is pretty active and focused
2 - Github orgs would allow for a connect or OpenID parent with individual repos for the various specs similar to other specification efforts using github (more focused issue trackers, permissions, build automations, etc)

If there's interest and no blockers, I'm also volunteering to help do the work of the migration.

Thanks!

Jer

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb54c63244c2d44fecb9508db01bce391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638105683162407570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=u7troplRZULQ1z0MMRXnVHYtYL4rYWPAm7SWkvmkWIw%3D&reserved=0>

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb54c63244c2d44fecb9508db01bce391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638105683162407570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=u7troplRZULQ1z0MMRXnVHYtYL4rYWPAm7SWkvmkWIw%3D&reserved=0>
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb54c63244c2d44fecb9508db01bce391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638105683162407570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=u7troplRZULQ1z0MMRXnVHYtYL4rYWPAm7SWkvmkWIw%3D&reserved=0>

--
Nat Sakimura
NAT.Consulting LLC
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb54c63244c2d44fecb9508db01bce391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638105683162563796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=%2FbfTKSCkO5ju2jnYF87m9U2PoPYP1slG4Xq5gwykGBA%3D&reserved=0>

--
Nat Sakimura
NAT.Consulting LLC
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb54c63244c2d44fecb9508db01bce391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638105683162563796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=%2FbfTKSCkO5ju2jnYF87m9U2PoPYP1slG4Xq5gwykGBA%3D&reserved=0>

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb54c63244c2d44fecb9508db01bce391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638105683162563796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=%2FbfTKSCkO5ju2jnYF87m9U2PoPYP1slG4Xq5gwykGBA%3D&reserved=0>

--
Nat Sakimura
NAT.Consulting LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230129/aedf2771/attachment-0001.html>