[Infrastructure] GitHub Branch Cleanup
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Mon Feb 3 11:51:26 MST 2020
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:
>> 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
>> 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
> 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
> 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
> 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
> or even more notably,
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Infrastructure