[cabfpub] Separate GitHub Repositories for Each Working Group

Aaron Gable aaron at letsencrypt.org
Thu Oct 8 00:26:33 UTC 2020


I have just a couple questions, none of which I think are important enough
to
count as objections or block this proposal from moving forward:

1) Has the Infrastructure Subcommittee considered the option of using
`git filter-branch` (or its easier-to-use unofficial cousin,
git-filter-repo:
https://github.com/newren/git-filter-repo/) instead of forking + deleting? I
believe that this solution would not work well for the new "servercert"
repo,
as the history rewrite would break redirects from old "documents" urls which
contain specific commit or blob hashes, but it might be a good option to
preserve full history (including of tools) for the other repositories if
that
is desired.

2) Given that the plan is for the "smime" and "code-signing" repositories to
retain the tooling necessary for building and deploying their documents (at
least until the "tools" repo is finalized), why are they being created fresh
instead of forked + deleted like the other, larger repositories? Having the
same creation process for all new repos, regardless of their size or the
importance of their documents' edit history, seems like a good idea.

3) Does the Infrastructure Subcommittee have a plan for preventing the
creation of orphan branches in the future, like those that will be deleted
from the "servercert" and "forum" repos? My understanding is that these
branches come into being representing proposed ballots which then fail to be
ratified. Are there proposals to clean up such branches on a regular ongoing
basis, or to prevent their creation in the first place (e.g. by having the
ballot pull request come from its sponsors' fork of the repo, rather than
from a branch within the repo itself)?

Thank you,
Aaron

On Wed, Oct 7, 2020 at 8:33 AM Wayne Thayer via Public <public at cabforum.org>
wrote:

> The Infrastructure Subcommittee plans to change the structure of the
> Forum's GitHub 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:
>
> First, we'll clone the "documents" repository to "archive", preserving
> branches and commit history.
>
> We'll then rename "documents" to "servercert". This repo will contain the
> SCWG Charter, BRs, and EVGLs. GitHub 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.
>
> 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".
>
> 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.
>
> Finally, we'll create new repositories under the 'cabforum' organization
> as follows:
> - "code-signing" - Code signing Charter, BRs, and EV code signing
> guidelines
> - "smime" - Charter and BRs for S/MIME certificates
> - "tools" - Future location for automation code and other Infrastructure
> WG files
>
> The few commits that need to be preserved in these repos will be manually
> re-created.
>
> 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).
>
> The "main" branch of each repo will be configured to enforce reviews
> before merging a pull request.
>
> 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.
>
> Thanks,
>
> Wayne
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20201007/f1d05141/attachment-0002.html>


More information about the Public mailing list