<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 1:09 PM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
During the latest SC33 merge into main,<br>
<br>
Wayne had to do some additional commits to bring the pull request up to <br>
speed before being able to create a merge request for SC33.<br>
<br>
According to the current process documented in <br>
<a href="https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chair_onlyactions_before_the_ipr_review_period_chair_or_vice_chair" rel="noreferrer" target="_blank">https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chair_onlyactions_before_the_ipr_review_period_chair_or_vice_chair</a>,<br>
<br>
step 3. says "Open the existing “Pull Request” that contains the <br>
immutable red line.".<br>
<br>
In some of the recent ballots (SC33, SC28) there were no pull requests <br>
but instead just immutable compare links. My first question is how can <br>
the Chair (or Vice Chair) create such a pull request, when the changes <br>
are in a private fork (e.g. Neil's or Wayne's fork)?<br></blockquote><div><br></div><div>You can open a PR against cabforum from their repository (from the compare link).</div><div><br></div><div>Alternatively,  you can fork their fork (which will have all the same commit hashes) into a copy of your own, and open the PR. </div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Assuming there is such a pull request in some private fork, and assuming <br>
that there has already been an update in the Baseline Requirements <br>
document in between, the workflow should be updated to include some <br>
additional steps in the forked repo:<br>
<br>
3a: re-sync the forked repo with the cabforum/documents main branch. How <br>
does this "re-sync" process look like from a practical standpoint?<br></blockquote><div><br></div><div>Our existing documentation should cover this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3b: resolution of any conflicts so that the end result of the pull <br>
request will be against the "latest" version of the BRs in <br>
cabforum/documents main<br></blockquote><div><br></div><div>This is the more problematic part, because our Bylaws very clearly state that, in Section 2.4:</div><div><br></div><div>"Such redline<br>or comparison shall be made against the Final Guideline section(s) as they exist<br>at the time a ballot is proposed, and need not take into consideration other<br>ballots that may be proposed subsequently, except as provided in Section 2.4(10)<br>below."<br></div><div><br></div><div>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</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Are there any other issues to consider? I know that Wayne spent some <br>
time doing this over SC33 so he could share his experience so we can all <br>
help updating the documentation on the wiki.<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<br>
PS: I will soon need to do this when the IPR review period is over for <br>
SC28 and SC35</blockquote><div><br></div><div>Did you mean SC33 here? SC35 followed this process </div></div></div>