Re: [cabfpub] Separate GitHub Repositories for Each Working Group
On Wed, Oct 7, 2020 at 8:27 PM Aaron Gable via Public 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. ___ Public mailing list Public@cabforum.org https://lists.cabforum.org/mailman/listinfo/public
Re: [cabfpub] Separate GitHub Repositories for Each Working Group
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 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@cabforum.org > https://lists.cabforum.org/mailman/listinfo/public > ___ Public mailing list Public@cabforum.org https://lists.cabforum.org/mailman/listinfo/public
[cabfpub] Separate GitHub Repositories for Each Working Group
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@cabforum.org https://lists.cabforum.org/mailman/listinfo/public
