<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
This is really helpful, thanks!<br>
<br>
If anyone can find the time, it would be great to have some quick
instructions on how to add "tags" on GitHub using the web UI. I
could even use the local git CLI if it's easier to do that.<br>
<br>
I believe the end goal is to add version tags for each produced
Final Guideline.<br>
<br>
<br>
DZ.<br>
<br>
<div class="moz-cite-prefix">On 21/8/2020 6:31 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvYh-9Yin3xg3Ji2XAshsDxnDv+EaWvKeMjS1e9BjJpNDQ@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, Aug 21, 2020 at
11:30 AM Ryan Sleevi <<a href="mailto:sleevi@google.com"
moz-do-not-send="true">sleevi@google.com</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">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Aug 21, 2020
at 5:10 AM Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr" target="_blank"
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">
<div> <br>
<br>
<div>On 20/8/2020 9:07 μ.μ., Ryan Sleevi wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Aug
20, 2020 at 11:56 AM Dimitris Zacharopoulos
(HARICA) <<a
href="mailto:dzacharo@harica.gr"
target="_blank" 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>
I followed <br>
<a
href="https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chairactions_after_the_ipr_review_period"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chairactions_after_the_ipr_review_period</a>
<br>
for SC30 and SC31 based on the existing pull
request and review <br>
(<a
href="https://github.com/cabforum/documents/pull/203"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://github.com/cabforum/documents/pull/203</a>). </blockquote>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> </blockquote>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> The
process had a step to delete the temporary
branch <br>
(Ballot-SC30-and-31), which I did.
Unfortunately, this also closed <br>
<a
href="https://github.com/cabforum/documents/pull/207"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://github.com/cabforum/documents/pull/207</a>
because it was depending <br>
on the temporary branch Ballot-SC30-and-31.<br>
<br>
Ryan, is this something you can fix? </blockquote>
<div><br>
</div>
<div>Yes, it's no big deal and what I expected
to happen.</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">We should
probably update the <br>
instructions accordingly.<br>
</blockquote>
<div><br>
</div>
<div>For what? I used a non-standard approach
that intentionally isn't documented to begin
with ;-)</div>
</div>
</div>
</blockquote>
<br>
No objections to this approach. What I meant by
"update the instructions" was more of adding a
"hint" to ballot proposers with language on how to
avoid such situations (e.g. "Use separate branches
for follow-up ballots..." or "don't create new
ballots on branches that are used for PR against the
main cabforum/documents branch"). I didn't intend to
change the existing workflow if it wasn't necessary.
You might be perfectly familiar with how Git repos
work and interact with each other, but another
ballot proposer might get confused :)<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>I think we likely want to focus our
documentation on common, normal flows
intended for those not wanting to learn Git
or GitHub (totally understandable) or the
Chair and Vice-Chair to produce results, and
don't need to try to document every scenario
or use case. Weird edge cases (like where
I've created multiple branches to show
in-progress stuff) is something I think we
can and should deal with on an ad-hoc basis,
because it's rare, exceptional, and trying
to document all the edge cases just
introduces more room for failure.</div>
</div>
</div>
</blockquote>
<br>
I agree.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> <br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> I also
went to download the artifacts <br>
(<a
href="https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/main/BR.docx"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/main/BR.docx</a>)
<br>
after the merge, but they were not updated
according to the last <br>
commits. I assume that the artifacts are
created the first time you <br>
create the pull request and not when you add
commits to that pull <br>
request afterwards. Is that correct?<br>
</blockquote>
<div><br>
</div>
<div>No. The artifacts are generated for every
commit.</div>
<div><br>
</div>
<div>It's not clear to me what you're
describing, so hopefully you can clarify.
The URL you linked is only updated after you
merge the commit. </div>
</div>
</div>
</blockquote>
<br>
I merged the commit and waited a few minutes before
downloading the docx artifact, but the document was
old.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>If you want to view commits as you add
them to the PR, before it is merged, the
link is to the branch name - e.g. <a
href="https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/Ballot-SC30-and-31/BR.docx"
target="_blank" moz-do-not-send="true">https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/Ballot-SC30-and-31/BR.docx</a></div>
<div><br>
</div>
<div>If you added commits to the branch after
you merged, and did not merge those, don't
do that, that's not part of any documented
instruction :)</div>
</div>
</div>
</blockquote>
<br>
This practice is avoided, and I believe we have
configured the repo to technically forbid that (i.e.
require at least a review by a second repo
maintainer before merge to main is allowed).<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> What
would be the best way to generate these
artifacts now? We probably <br>
need to update the workflow to include steps
to create the artifacts <br>
after the last merge.<br>
</blockquote>
<div><br>
</div>
<div>Doubtful! It's probably just that you
didn't let the update process complete :)</div>
<div><br>
</div>
<div><a
href="https://travis-ci.org/github/cabforum/documents/builds/719653438"
target="_blank" moz-do-not-send="true">https://travis-ci.org/github/cabforum/documents/builds/719653438</a>
shows it took 2 minutes and 6 seconds to
generate the artifacts. Did you try to view
immediately after committing, and before 2
minutes and 6 seconds had passed?</div>
<div><br>
</div>
<div>This is one of those things that is in
the file of "improvements to consider"
(switching to <a
href="https://github.com/cabforum/documents/projects/1#card-41784176"
target="_blank" moz-do-not-send="true">GitHub
actions</a>, so it adds the UI signals). </div>
</div>
</div>
</blockquote>
<br>
I could almost swear that I waited more than 2
minutes and 6 seconds before trying to download the
artifacts, but apparently I didn't :-)<br>
<br>
Next time I will be more patient and wait, until we
manage to have UI signals for the CI.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Right now, <a
href="https://travis-ci.org/github/cabforum/documents/builds/"
target="_blank" moz-do-not-send="true">https://travis-ci.org/github/cabforum/documents/builds/</a></div>
<div><br>
</div>
<div>But I almost hesitate to document that, because I'd
like to fix that "real soon" (modulo time
commitments), since the GitHub Actions would let you
view it directly (as an attached artifact) </div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Oh, and I suppose one bit I should have clarified: you
don't need to run the build after the merge. If your branch
is mergable and in sync, the branch's copy of the document
is going to be identical to the main repo. So just grab the
copy from the PR branch, which does have UI signals already
(which also shows the CI status as failing, running, or
successful per-commit)</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>