[Infrastructure] GitHub Branch Cleanup

[Dimitris Zacharopoulos (HARICA)]

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.

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
 2. 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
 3. Allow for post-mortem verification that the redline we voted on
    matches the final language that was incorporated in the Master.

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 :-)


Thanks,

Dimitris.



>
> On Mon, Feb 3, 2020 at 12:16 PM Ryan Sleevi <sleevi at google.com 
> <mailto:sleevi at google.com>> wrote:
>
>     Let's first talk about your goals, before we settle on implementation.
>
>     What's your particular goal? The whole reason we switched to Git
>     was to have an unambiguous history. That history is preserved
>     through Git itself, so in the stable case - e.g. a ballot is
>     accepted - the thing we want to preserve is the change itself, and
>     that can still be and is preserved.
>
>     If the goal is something different, we should nail down what that
>     is. For example, we've already touched on how to unambiguously
>     ensure there are no modifications during or following the voting,
>     which is the previous concern that had been articulated. We
>     haven't guaranteed that Forum infrastructure items are preserved
>     (for example, the loss of our Wiki editing history during the
>     system migration in 2017), nor have we preserved all the
>     attachments that used to be distributed through the Wiki itself,
>     so I can't imagine it's just to preserve the links.
>
>     If you can articulate the scenario you want to preserve, and the
>     set of concerns, then that will help us figure out how best to
>     accommodate that.
>
>     For example, the nice thing about the GitHub approach is that you
>     can reliably verify the pull request is what was actually
>     integrated and committed.
>
>     On Mon, Feb 3, 2020 at 12:00 PM Dimitris Zacharopoulos (HARICA)
>     <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>         I have some general concerns about loosing the "immutable"
>         redline version that we vote on. If someone deletes a branch
>         (private fork or in the cabforum), the immutable link to the
>         redline that was voted on will be broken.
>
>         If this is true, then I think we need to have an improved
>         process where a private fork is "copied" back to the
>         cabforum/documents repo, and made read-only or something. Of
>         course I am not a git expert so I'm asking here to get some
>         reassurances that deleting branches will not create
>         unintentional gaps.
>

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