[Infrastructure] GitHub Branch Cleanup

[Dimitris Zacharopoulos (HARICA)]

On 2020-02-03 8:09 μ.μ., Ryan Sleevi wrote:
>
>
> On Mon, Feb 3, 2020 at 12:46 PM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>
>
>     On 2020-02-03 7:22 μ.μ., Ryan Sleevi wrote:
>>     More concretely, as an example:
>>
>>     Here's a patch from over 2 years ago I sent to a repository:
>>     https://github.com/chromium/web-page-replay/pull/91
>>
>>     It's from a branch I deleted, from a repository I deleted.
>>
>>     Yet, because I opened a pull request, you can still download
>>     https://patch-diff.githubusercontent.com/raw/chromium/web-page-replay/pull/91.patch and
>>     see exactly what commits I made, against what version of the
>>     'upstream' repository, and reproduce them exactly to get the same
>>     diff.
>>
>>     This is why I keep asking folks to create Pull Requests for
>>     proposed Ballots. It's the Pull Request that gives us immutability.
>
>     The goal was for someone to be able to verify that the changes to
>     Master were in fact in sync with the proposed language of the
>     ballot. We should try to preserve this, as we have seen mistakes
>     happening before when merging the ballot to the master branch.
>
>
> So the pull request workflow already preserves this, if you use the 
> opened pull request. The error-prone process is when you start trying 
> to duplicate or recreate, which we saw in the ballot trying to combine 
> SC23 and SC24 into a single commit, which isn't needed.
>
>     I'd like us to discuss (offline or on this list if you want) about
>     documenting the exact steps that a ballot proposer and the Chair
>     or Vice-Chair need to follow in order to achieve two goals:
>
>      1. Create an immutable redline that members can vote on
>
> This starts with as simple as opening up a pull request and 
> referencing specific commits. The ad-hoc/bespoke proposals get messier 
> here.
>
>      1. Create a final version in the Master branch that includes the
>         changes of the ballot plus some informational changes like
>         version number, table of changes, table of relevant dates
>
> If a pull request is opened with edit privileges, then the admin (aka 
> chair / vice chair or their delegates) can edit those sections as 
> secondary commits (i.e. based on the one we voted on). So it can be 
> clearly and unambiguously demonstrated that a given change was part of 
> something.
>
>      1. Allow for post-mortem verification that the redline we voted
>         on matches the final language that was incorporated in the Master.
>
> The point of Git is that the content-addressed storage lets us 
> unambiguously guarantee that the hash-in-the-ballot matches the 
> hash-as-merged.
>
> For example, if Doug's ballot was opened as a PR (for 
> https://github.com/cabforum/documents/compare/master...dougbeattie:Ballot-SC25-v1 ), 
> then you get nice properties, like 
> https://github.com/cabforum/documents/commit/bb90ff37c4bc043636229138d9923fcff670cdfc.patch - 
> a formatted patch file.
>
> However, more generally, once a ballot is merged, do we need to keep 
> the branch around forever? I don't think so, so if there's something 
> I'm overlooking that causes disagreement, we should nail that down.
>
>     So, if the process requires to create a pull request in order to
>     satisfy these properties, let's document this. It will get us one
>     step closer to using GitHub as the canonical version for our
>     Guidelines :-)
>
> Sure, but I think that's largely orthogonal to the branch-deleting 
> problem, then.
>
> More generally, I don't think now is the right time to bring up that 
> objection, if only because it's been largely ignored for previous 
> ballots. Examples such as 
> https://cabforum.org/2019/05/21/ballot-sc19-phone-contact-with-dns-caa-phone-contact-v2/ or 
> https://cabforum.org/2019/05/01/ballot-sc18-phone-contact-with-dns-caa-phone-contact/, 
> or even more notably, 
> https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/ 
> show this.
>
> To the topic of removing branches from 'upstream', it seems we've got:
> 1) Branches created by Chairs / Vice-Chairs / folks with admin access, 
> none of which are needed and "shouldn't" have been created (vs in 
> personal repository)
> 2) Branches created in the past to match ballots, but only to keep the 
> markdown in sync with the Word docs, and not part of ballots themselves
> 3) Branches created by folks with admin privileges that were used in 
> ballots, rather than personal repositories
>
> I'm saying we should unambiguously delete all three. I don't believe 
> the situation in #3 is worse than the situation we have (e.g. Doug's 
> Ballots SC18 or SC19 as an example), and so I don't think we should 
> hold off deleting them just because other ballots (like SC17) used 
> branches-in-upstream, especially since we've verified they've been 
> merged as expected.
>
> If the concern is wanting to verify 2-3 years down the road, based 
> solely on e-mail archives but presuming we have zero git archives, 
> that's a different thing entirely. The point is to make it possible to 
> have the git archives (and anyone can fork and/or archive)


I do not oppose removing all previous "experimental" branches, etc. As 
you noted, there were several people engaging in this activity without 
clear instructions, git knowledge (including me of course) or a clear 
documented process. We are getting better at this and already have a 
somewhat documented procedure to create redline versions by using a 
local repository. I think we should nail down the procedure, check its 
results and if everything works as expected, then remove the old 
branches. How does that sound?

Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/infrastructure/attachments/20200203/690e714b/attachment.html>