[Infrastructure] GitHub Branch Cleanup

[Ryan Sleevi]

On Mon, Feb 3, 2020 at 12:46 PM Dimitris Zacharopoulos (HARICA) <
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/infrastructure/attachments/20200203/b3603159/attachment-0001.html>