[Infrastructure] Updated instructions for GitHub ballot merge after IPR review

Ryan Sleevi sleevi at google.com
Fri Sep 25 10:16:57 MST 2020


On Fri, Sep 25, 2020 at 1:09 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
> During the latest SC33 merge into main,
>
> Wayne had to do some additional commits to bring the pull request up to
> speed before being able to create a merge request for SC33.
>
> According to the current process documented in
>
> https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chair_onlyactions_before_the_ipr_review_period_chair_or_vice_chair
> ,
>
> step 3. says "Open the existing “Pull Request” that contains the
> immutable red line.".
>
> In some of the recent ballots (SC33, SC28) there were no pull requests
> but instead just immutable compare links. My first question is how can
> the Chair (or Vice Chair) create such a pull request, when the changes
> are in a private fork (e.g. Neil's or Wayne's fork)?
>

You can open a PR against cabforum from their repository (from the compare
link).

Alternatively,  you can fork their fork (which will have all the same
commit hashes) into a copy of your own, and open the PR.

These are steps that can be done at any point in the balloting process, and
we suggested in the past that the infrastructure group could help out
anyone who had trouble with this / doesn't want to go through the main.


> Assuming there is such a pull request in some private fork, and assuming
> that there has already been an update in the Baseline Requirements
> document in between, the workflow should be updated to include some
> additional steps in the forked repo:
>
> 3a: re-sync the forked repo with the cabforum/documents main branch. How
> does this "re-sync" process look like from a practical standpoint?
>

Our existing documentation should cover this.


> 3b: resolution of any conflicts so that the end result of the pull
> request will be against the "latest" version of the BRs in
> cabforum/documents main
>

This is the more problematic part, because our Bylaws very clearly state
that, in Section 2.4:

"Such redline
or comparison shall be made against the Final Guideline section(s) as they
exist
at the time a ballot is proposed, and need not take into consideration other
ballots that may be proposed subsequently, except as provided in Section
2.4(10)
below."

This was the same issue with the Word doc, but now we have programmatic
enforcement that ballots aren't stomping eachother, and if they do, to
resolve them as described in Section 2.4 of the Bylaws


> Are there any other issues to consider? I know that Wayne spent some
> time doing this over SC33 so he could share his experience so we can all
> help updating the documentation on the wiki.
>
>
> Thanks,
> Dimitris.
>
> PS: I will soon need to do this when the IPR review period is over for
> SC28 and SC35


Did you mean SC33 here? SC35 followed this process
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/infrastructure/attachments/20200925/31200634/attachment.html>


More information about the Infrastructure mailing list