[Infrastructure] Separate GitHub Repositories for Each Working Group

Wed Sep 23 15:26:25 MST 2020

Looks good to me.

On Wed, Sep 23, 2020 at 10:47 AM Wayne Thayer <wthayer at gmail.com> wrote:

> Here is an updated draft announcement based on my understanding of today's
> discussion:
>
> 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 on
> November 1st if there are no objections. Please respond if you have any
> concerns with this proposal.
>
> On Thu, Sep 10, 2020 at 8:42 AM Ryan Sleevi <sleevi at google.com> wrote:
>
>> I think you're asking two separate things?
>>
>> There's the branch history (e.g. branches created by Ben and Dimitris for
>> merging), which we were holding off just to make sure we dealt with any
>> stable links.
>> But there's also the commit history (e.g. the history of each commit),
>> which allows for line-by-line change history through every change. I
>> absolutely use that on a regular basis, and that's one of the things I
>> think we should preserve - to be able to git-blame through the ballot
>> history. That's why I'm hugely appreciative that Ben actually made each
>> ballot a commit, allowing the history to be tracked through the many
>> ballots.
>>
>> On Thu, Sep 10, 2020 at 11:31 AM Jos Purvis (jopurvis) <
>> jopurvis at cisco.com> wrote:
>>
>>> One question that came up in our discussion was how frequently anyone
>>> refers back to the old branches or changes that are part of the git history
>>> for /documents. Obviously the more recent changes are sometimes still
>>> relevant, but I’ve yet to find anyone deep-referencing something from the
>>> 100-branch of the ballot history for the BRs. And if someone wanted to do
>>> that, the history would all still be there under /documents, unchanged, and
>>> you could even git-compare /documents/docs/BR.md (or a historical version
>>> of it) with /scwg/docs/BR.md, no?
>>>
>>>
>>>
>>> I guess I’m wondering how much effort to spend focusing on preserving
>>> that history in each of the document trees vs. creating each new WG tree
>>> clean and letting /documents become /archive and retain that history for
>>> reference.
>>>
>>>
>>>
>>> --
>>> Jos Purvis (jopurvis at cisco.com)
>>> .:|:.:|:. cisco systems | Cryptographic Services
>>> PGP: 0xFD802FEE07D19105 | Controls and Trust Verification
>>>
>>>
>>>
>>>
>>>
>>> *From: *Infrastructure <infrastructure-bounces at cabforum.org> on behalf
>>> of Ryan Sleevi <sleevi at google.com>
>>> *Date: *Wednesday, September 9, 2020 at 3:04 PM
>>> *To: *Wayne Thayer <wthayer at gmail.com>
>>> *Cc: *"infrastructure at cabforum.org" <infrastructure at cabforum.org>
>>> *Subject: *Re: [Infrastructure] Separate GitHub Repositories for Each
>>> Working Group
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Sep 9, 2020 at 12:37 PM Wayne Thayer <wthayer at gmail.com> wrote:
>>>
>>> We discussed this proposal on today's Infrastructure subcommittee call.
>>>
>>>
>>>
>>> On Mon, Aug 31, 2020 at 9:46 AM Wayne Thayer <wthayer at gmail.com> wrote:
>>>
>>> Thanks Ryan - this is helpful.
>>>
>>>
>>>
>>> On Mon, Aug 31, 2020 at 9:32 AM Ryan Sleevi <sleevi at google.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Aug 31, 2020 at 12:16 PM Wayne Thayer <wthayer at gmail.com> wrote:
>>>
>>> During last week's Infrastructure call, Ben, Jos, and I discussed the
>>> proposal to split https://github.com/cabforum/documents/ into separate
>>> repositories for each WG's documents.
>>>
>>>
>>>
>>> FWIW, I tried for 10 minutes to get into the call before giving up. Can
>>> we get this worked out for the next call? Had the same problem with our
>>> prior call as well.
>>>
>>>
>>>
>>>
>>>
>>> No one has been able to start the meeting. Jos is working with the WebEx
>>> team to get his account fixed.
>>>
>>>
>>>
>>> I don't believe that we need to create a ballot to proceed with this
>>> change, but I suggested that we should announce the change on the public
>>> list and give members a chance to object to it. Here is what I think we
>>> want to propose:
>>>
>>> ================
>>>
>>> The Infrastructure Subcommittee plans to change the structure of the
>>> Forum's GitHub organization to better reflect the evolving structure of the
>>> Forum itself.
>>>
>>>
>>>
>>> We'll create new repositories under the 'cabforum' organization as
>>> follows:
>>>
>>> - "forum" - contains the Bylaws (and potentially IPR agreement and other
>>> Forum level docs)
>>>
>>> - "servercert" - Charter, BRs, and EVGLs
>>>
>>> - "code-signing" - Code signing Charter, BRs, and EV code signing
>>> guidelines
>>>
>>> - "smime" - Charter and BRs for S/MIME certificates
>>>
>>> - "tools" - automation code and other Infrastructure WG files
>>>
>>>
>>>
>>> "tools" is a bit TBD right now. That's specifically a large scale of
>>> work (to work out the CI integration and templates and figuring out if
>>> we're doing cross-repo syncs). So let's just place this as "TBD". I think
>>> just focusing on the main work products sounds good.
>>>
>>>
>>>
>>>
>>>
>>> I think this means that all of the automation for producing the
>>> documents would initially be duplicated in each repo. We agreed that is a
>>> good approach because it allows us to proceed with the separate repos
>>> sooner. Then a subsequent task would be to consolidate the automation for
>>> all the repos into the 'tools' repo so that the Infrastructure subcommittee
>>> can more easily maintain it.
>>>
>>>
>>>
>>> As I wasn't able to make the call, I'm not sure what was discussed for
>>> cabforum/documents - is that being renamed to that it will automatically
>>> redirect? I think we should, and should to servercert rather than forum,
>>> but that wasn't clear.
>>>
>>>
>>>
>>>
>>>
>>> That makes sense.
>>>
>>>
>>>
>>>
>>>
>>> We decided that it would be best to consider cabforum/documents a legacy
>>> repo, set it to read-only, and possibly rename it to 'archive' rather than
>>> repurposing it as either the forum level repo or the SCWG repo.
>>>
>>>
>>>
>>> Thanks, but I think I'm still concerned about this. Can folks share the
>>> rationale?
>>>
>>>
>>>
>>> Ben is proceeding with some branch cleanup work, but in today's call we
>>> decided that keeping the cabforum/documents repo intact as an archive would
>>> allow us to create the new repos from scratch without copying over history
>>> and branches. We can proceed with this approach to creating the new repos
>>> without branch cleanup in the cabforum/documents repo.
>>>
>>>
>>>
>>> I'm not sure this is good either, and hoping to share the rationale. I
>>> do not think breaking the version history into multiple repositories is at
>>> all consistent with our goals for moving to versioned artifacts to begin
>>> with, and I'm concerned that just like our Wiki migrations, we'll lose
>>> important change control history that remains relevant.
>>>
>>>
>>>
>>> Is the sole goal just "do something sooner?" Or are there other reasons?
>>>
>> _______________________________________________
> Infrastructure mailing list
> Infrastructure at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/infrastructure/attachments/20200923/f0f16393/attachment-0001.html>