<div dir="ltr">I have just a couple questions, none of which I think are important enough to<br>count as objections or block this proposal from moving forward:<br><br>1) Has the Infrastructure Subcommittee considered the option of using<br>`git filter-branch` (or its easier-to-use unofficial cousin, git-filter-repo:<br><a href="https://github.com/newren/git-filter-repo/">https://github.com/newren/git-filter-repo/</a>) instead of forking + deleting? I<br>believe that this solution would not work well for the new "servercert" repo,<br>as the history rewrite would break redirects from old "documents" urls which<br>contain specific commit or blob hashes, but it might be a good option to<br>preserve full history (including of tools) for the other repositories if that<br>is desired.<br><br>2) Given that the plan is for the "smime" and "code-signing" repositories to<br>retain the tooling necessary for building and deploying their documents (at<br>least until the "tools" repo is finalized), why are they being created fresh<br>instead of forked + deleted like the other, larger repositories? Having the<br>same creation process for all new repos, regardless of their size or the<br>importance of their documents' edit history, seems like a good idea.<br><br>3) Does the Infrastructure Subcommittee have a plan for preventing the<br>creation of orphan branches in the future, like those that will be deleted<br>from the "servercert" and "forum" repos? My understanding is that these<br>branches come into being representing proposed ballots which then fail to be<br>ratified. Are there proposals to clean up such branches on a regular ongoing<br>basis, or to prevent their creation in the first place (e.g. by having the<br>ballot pull request come from its sponsors' fork of the repo, rather than<br>from a branch within the repo itself)?<br><br>Thank you,<br>Aaron<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 7, 2020 at 8:33 AM Wayne Thayer via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</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>The Infrastructure Subcommittee plans to change the structure of
the Forum's <span>GitHub</span> organization to better
reflect the evolving structure
of the Forum itself by moving to separate repositories for each working
group. We've discussed a number of ways to accomplish this, and have
concluded that the following steps represent the best approach:<br></div><div><br></div><div>First, we'll clone the "documents" repository to "archive", preserving branches and commit history.</div><div><br></div><div>We'll then rename "documents" to "servercert". This repo will contain the SCWG Charter, BRs, and EVGLs. <span>GitHub</span>
will automatically redirect links from the old name to the new name,
keeping links to the current versions of the BRs, NCSSRs, and EVGLs
functioning.<br></div><div><br></div><div>The "servercert" repo will be
forked to create a "forum" repo that retains commit history for the
Charter and other Forum level documents. Non-SCWG documents will then be
deleted from "servercert", and non-Forum docs will be deleted from
"forum".<br></div><div><br></div><div>Also, ALL EXISTING BRANCHES WILL
BE DELETED - this means that some redline links included in old ballots
will be broken. Those links can be manually modified to reference the
"archive" repository. This is a tradeoff made to preserve links to the
current versions of SCWG docs and to simplify this migration.<br></div><div><br></div><div>Finally, we'll create new repositories under the 'cabforum' organization as follows:</div><span><div>- "code-signing" - Code signing Charter, BRs, and EV code signing guidelines</div><div>- "smime" - Charter and BRs for S/MIME certificates</div></span><div>- "tools" - Future location for automation code and other Infrastructure WG files</div><div><span><br></span></div><div>The few commits that need to be preserved in these repos will be manually re-created.</div><span><div><br></div><div>Each
repo will have access rights specific to the working group (e.g. SCWG
members won't be able to approve changes to the SMCWG repo).<br></div><div><br></div></span><div>The "main" branch of each repo will be configured to enforce reviews before merging a pull request.</div><div><br></div><div>The
Infrastructure subcommittee proposes that these changes be made after
November 1st if no objections are raised. Please respond if you have any
concerns with this proposal.</div><div><br></div><div>Thanks,</div><div><br></div><div>Wayne<br></div></div>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/public</a><br>
</blockquote></div>