[cabfpub] Separate GitHub Repositories for Each Working Group

[Ryan Sleevi]

On Wed, Oct 7, 2020 at 8:27 PM Aaron Gable via Public <public at cabforum.org>
wrote:

> 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.
>

Yeah, this was effectively the approach desired for:
> The few commits that need to be preserved in these repos will be manually
re-created.

Namely, the non-"servercert" repos would only have the commits relevant for
the appropriate documents preserved (i.e. there's no need for the
codesigning repo to preserve edits to the BRs)


> 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.
>

The number of commits outside of the servercert WG, affecting the other
documents, was something like less than two dozen, and most of that was
largely the Bylaws.

I'm not sure the benefit of the same creation process? The benefit here is
you wouldn't need to download 8+ MB of unrelated diff-history when cloning
the repro. Mostly, the discussion was how "Everything other than
servercert-wg can be done by hand in a few minutes, so no need to have a
massive process here".


> 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.
>

The Ballot Instructions specifically provide guidance to avoid this. The
affected branches are largely those affected prior to the adoption of those
requirements. It also related to fact that previously, almost every member
of the /documents repo had the ability to directly commit to "main" and had
the ability to create branches.

The model captured in the Wiki tries to encourage the fork+(do work in your
fork), rather than the unfortunate situation in the past where some commits
were directly on "main" and some were in branches off the main /documents


> 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)?
>

Exactly this. We've already turned off the direct write access to "main",
and even admins are required to go through a PR-review process to land
commits there. The workflow documented on the Wiki also provides
instructions for how to provide stable links. We've also been working to
update the continuous integration so that artifacts are produced on PRs,
specifically PRs from sponsors' forks, by looking at switching from Travis
to GitHub Actions and streamlining the process. Under the current Travis
integration, there was a bias to using cabforum/documents branches because
that allowed the CI to run with the AWS secrets, so that's why that
sometimes happened from infrastructure WG members, to ensure that document
previews (for review and for IPR) would be generated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20201007/fd07af58/attachment.html>