Re: Merging git history for jws-2020

On 7/19/22 2:41 PM, Orie Steele wrote:
> On Tue, Jul 19, 2022 at 12:25 PM Manu Sporny <msporny@digitalbazaar.com
>     Can PR history be transferred? Can closed issues be transferred? 'cause that's
>     part of the problem as well.
> 
> Yes, and in fact, its best preserved by my recommended approach.

We might be talking past each other. I think you might be thinking "commit
history", which is different from "PR history". By "PR history" I mean, this
stuff and all of the conversations around the PR:

https://github.com/w3c-ccg/vc-api/pulls?q=is%3Apr+is%3Aclosed+is%3Aopen

Issues have a "Transfer Issue" button.

PRs have no such button.

PR history is important because 1) we use it to calculate who the contributors
are at the end (contribution to issue and PR discussion get you authorship),
and 2) You can track down exactly where a line in the spec came from (and the
discussion that surrounded it) which is useful when anyone is trying to figure
out why a particular feature exists in the spec. For example, this discussion
around the initial GET and DELETE operations wouldn't show up in a search:

https://github.com/w3c-ccg/vc-api/pull/271

If the PR history exists in two places, it becomes much harder to do a single
search to track stuff down, which adds extra time the Editors must spend when
trying to get an idea of where a particular feature/edit came from... which is
important when you're trying to find the set of people to include in a
discussion around a particular feature.

If we just transfer the repo, we keep everything intact.

> We did exactly this process for the DID Spec registries, and it successfully
> preserved history.

It didn't, for example, these 10 issues were not moved over:

https://github.com/w3c-ccg/did-method-registry/issues?q=is%3Aissue+is%3Aclosed

These 89 PRs and the discussions around them weren't moved over:

https://github.com/w3c-ccg/did-method-registry/pulls?q=is%3Apr+is%3Aclosed

IOW, we lost history on a registry that is supposed to track where DID Methods
come from and the process around the acceptance of each DID Method.

Now, you can argue "Oh, they're still there -- you just have to look in two
places"... which is exactly the point -- let's not make things harder on
ourselves by splitting history between two repos.

> It is a better approach, it preserves history and doesn't break links or
> create confusion.

I hope the above demonstrates how history is broken when we take the "manually
migrate SOME of the history by hand" approach.

> I don't like transfering because it blurs the line between the W3C CCG and the
> W3C, and I believe it's better to keep their histories and contexts intact and
> related... 

Why do you believe that?

> it also keeps the credit in the W3C CCG for starting the work

A simple line in the spec would accomplish this as well (as would the full
commit history).

IIRC, there is a trade-off here -- once we migrate the repos, and Github sets
up the redirects, I don't think we can create another repo with the same name
in the w3c-ccg (the link will always be redirected). This was a bug in Github
a few years ago that they said would be fixed, but I haven't gone back to see
if they actually fixed this bug. If they didn't, we'd run the risk of people
going to old versions of the HTML spec and getting a 404 (but then, a simple
google search would help them find the right URL). We'll need to run this
experiment to see if that is still an issue, and if it isn't, we can
accomplish everything that you want as well as everything that I want.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Wednesday, 20 July 2022 13:05:28 UTC