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

Kristina Yasuda Kristina.Yasuda at microsoft.com
Thu Jan 26 06:00:41 UTC 2023 

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> on behalf of Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net>
Sent: Wednesday, January 25, 2023 9:00 PM
To: Aaron Parecki <aaron at parecki.com>
Cc: nat <nat at nat.consulting>; Artifact Binding/Connect Working Group <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%7C5bb9996d26824b37849e08daff5a1bf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638103060208050819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=Xpzx5%2BrKFW%2F%2FoI297xIVEHSQvC6YEzpIm0oY9Av2eb8%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%7C5bb9996d26824b37849e08daff5a1bf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638103060208050819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=08SYvXRG0OEUMNuWxDojhbBPu7OdeRH8Fuql3T0O%2FUg%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%7C5bb9996d26824b37849e08daff5a1bf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638103060208050819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=pF%2Bx%2FT1Dd7pcTx5A%2BV3eR0xfBkPwX0DSlaEGRLVY0Ao%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%7C5bb9996d26824b37849e08daff5a1bf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638103060208050819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=BdiCHHXLjMWLTVTB0V%2BVLFDDwgSXektWar%2FJDevPr4U%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%7C5bb9996d26824b37849e08daff5a1bf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638103060208050819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=BdiCHHXLjMWLTVTB0V%2BVLFDDwgSXektWar%2FJDevPr4U%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%7C5bb9996d26824b37849e08daff5a1bf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638103060208207076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=DIOr8j5vJA00zkRUF4vBdywtaJJ2iBOxTvlhBe59hs8%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%7C5bb9996d26824b37849e08daff5a1bf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638103060208207076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=DIOr8j5vJA00zkRUF4vBdywtaJJ2iBOxTvlhBe59hs8%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/20230126/095be010/attachment-0001.html>

More information about the Openid-specs-ab mailing list