<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 2020-09-25 8:16 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvYe=r0d7p8t_sj+=8_sUMtRwP1PESQvGfCKwyaA2m8dVA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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>
</blockquote>
<br>
SC33 is already merged, so I only have SC28 and SC35. SC35 is
already merged in a new branch
(<a class="moz-txt-link-freetext" href="https://github.com/cabforum/documents/tree/SC35">https://github.com/cabforum/documents/tree/SC35</a>) and the pull
request (<a class="moz-txt-link-freetext" href="https://github.com/cabforum/documents/pull/208">https://github.com/cabforum/documents/pull/208</a>) shows as
"merged". However the SC35 branch shows "out of sync"?<br>
<br>
<img src="cid:part3.47735BAB.595D0128@harica.gr" alt="" width="598"
height="95"><br>
<br>
When the time comes to merge to Main, what would be the best way to
do it along with SC28? Perhaps it would be best to first squash and
merge SC28 to Main, then do the same for SC35 and update tables,
versions, etc.<br>
<br>
Thoughts?<br>
Dimitris.<br>
</body>
</html>