[Infrastructure] GitHub Branch Cleanup

[Ryan Sleevi]

On Mon, Feb 3, 2020 at 11:01 AM Jos Purvis (jopurvis) <jopurvis at cisco.com>
wrote:

> I like the idea! A couple things:
>
>    - I think there’s a case to be made for a few persistent branches,
>    most notably a “cleanup” branch to be used for accumulating changes for the
>    periodic cleanup ballots.
>
> I don't think this needs to be as part of the CA/B Forum master repository
though, do you? This seems like it can/should be part of an individual
fork. Certainly, it worked fine for our last cleanup ballot. When Tim got
swamped with work, I was able to fork his branch, rebase it against the
latest GitHub, and continue to make changes.

I've been using the GitHub issue tracker to track the cleanup items we need
to address, as well as tag the issues as appropriate.


>
>    -
>    - Do you think there are any issues with merging personal forks
>    directly to master? I’m wondering about the possibility of someone getting
>    a ballot passed and then last-minute including extra changes from the
>    passed text before merging. Wondering if it would be better to create a
>    workflow like this:
>       1. User creates personal fork to generate ballot text.
>       2. When ballot text is ready for voting, a PR is created to merge
>       their fork to a ballot-specific branch (which allows one of the Github
>       ninjas to ensure only the right stuff is being selected for merge, no weird
>       changes, etc.).
>       3. CABF Ballot is based on the diff of the ballot-specific branch
>       and master.
>       4. If the ballot passes, the branch is merged to master and
>       deleted. If it fails, the branch is deleted.
>
> To make sure I understand the scenario you're worried about:
- A ballot is created, which indicates explicit hash X against explicit
hash Y as part of the ballot
- A PR is created that reflects those two hashes (which allows discussion,
proposed edits, etc)
- The ballot may be updated several times during discussion period, to
reflect those fixes/changes
- After voting, the proposer 'maliciously or accidentally' adds explicit
hash Z to their branch, which thus causes the PR accordingly, and the chair
/ vice chair 'maliciously or accidentally' merges hash Z against Y, instead
of hash X against Y?

The fix for that seems simple:
- If the PR has not been modified, the Chair/Vice-Chair can use that PR and
merge it in directly, confirming that 'explicit hash X' from the ballot is
the latest commit from that PR
- If the PR has been modified, the Chair/Vice-Chair creates a branch (in
their personal repository or the CA/B Forum repository) at 'explicit hash
X', creates a PR, and uses that to merge

Since the Chair/Vice-Chair may need to edit the Informative tables (e.g.
version number, effective dates), they may need to either edit the
proposers branch or their branch. This is 'easy' if the PR-proposer allows
edits from the cabforum/documents admin/owners (which is the default for
PRs), and which the branch facilitates.

I don't think there's any reason/need to use the cabforum/documents
repository as the means to host that branch, but provided it's deleted at
the end of the PR (or any PR fixups), that doesn't seem unreasonable.

Mostly, it just seems that our cabforum/documents repository
1) Should not have any branches in 'upstream', since there's only One
Canonical Version of the BRs
2) Could use 'tags' more effectively (to tag each version following ballot
adoption), but that's not part of this e-mail convo :P

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