From sleevi at google.com Wed Aug 5 10:15:01 2020 From: sleevi at google.com (Ryan Sleevi) Date: Wed, 5 Aug 2020 13:15:01 -0400 Subject: [Infrastructure] GitHub streamlining Message-ID: As we transition to GitHub-based workflows for some of our activities, I was curious if we should start collecting recommended workflows, in thinking about how permissions, contributions, and reviews should work. I've added these to the Infrastructure Project Board for now, until we can discuss on our next call. # Structure Right now, we do everything in github.com/cabforum/documents . On the Wiki, we segment out activity based on the CWG-level. Right now, we have the Forum-wide documents (Bylaws), the SCWG documents (BRs, EVGs, NSRs), and at least one CSC WG document (br-csc, which is just a text file). Many other SDOs take the approach of either using a repository-per-WG or even a repository-per-specification, or a mix of both. Per our Bylaws, each Final Guideline is the work product of an individual CWG ## Question We discussed a little on our prior calls, but should we consider: 1. A separate repository per WG (CWG, FWG)? 2. A separate repository per Final Guideline? I realize the SCWG NetSec Subcommittee has been considering how the NSRs might integrate in the BRs, and there were previous discussions of folding the EVGs into the BRs (and, previously, a ballot was held to formally state we should adopt RFC 3647 format for the EVGs to facilitate that), but neither of those have happened yet, so #2 might be onerous for the SCWG. But #1 seems good? ## Proposal If we adopt #1, concretely, this would be my proposed hierarchy: 1. cabforum/forum - Contains Bylaws.md, RFC3647_Template.md, SCWG-charter.md, SCMWG-charter.md - The charters are placed here since rechartering requires Forum-wide approval 2. cabforum/server - Contains BR.md, EVG.md, NSR.md 3. cabforum/code_signing - Contains br-csc 4. cabforum/smime - Contains any eventual documents for the S/MIME WG 5. cabforum/spec-tools - Avoiding a catchall name like 'infra', this is the set of tools used to build the specifications (e.g. pandoc, weasyprint, etc) # Permissions Independent of whether we adopt the structure suggested above (although hopefully in concert with it), should we adjust the permissions so that the relevant Chair/Vice-Chair shall approve changes to the documents? Specifically, we can use permissions to create Github teams like "SCWG-Officers" and "CSC-Officers", which will contain the GitHub IDs of the Chair and Vice Chair, and require that the officer approve a merge for the respective documents. If we use a single repository, we'd likely accomplish this via CODEOWNERS If we use a multiple repository (as above), we could use repository permissions. ## Question Are there any concerns with going ahead and doing this now, given that teams are managed at the organization level (i.e. the "cabforum" level), so we can just use the CODEOWNERs approach until we decide on structure? # IPR Agreement As folks know, at the Forum level, we require participation to be accompanied by the IPR Agreement. This is conceptually similar to a CLA within open-source. It seems like we could use an automated webhook to validate that those opening PRs (and potentially issues?) have signed the IP Agreement. ## Question Are there concerns with using a tool like https://colineberhardt.github.io/cla-bot/ to automate verification that the GitHub user is mapped to a Forum Member or Interested Party and has the IPR agreement on file? Since the IP Agreement is Forum Wide, this would be creating something like https://github.com/cabforum/cla-config/ (as a private repository) to track the Forum-wide config, and that'd apply to all of the cabforum/ Organization, if we go the route of multiple repositories, or it could be done within cabforum/documents itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwilson at mozilla.com Wed Aug 5 13:40:15 2020 From: bwilson at mozilla.com (Ben Wilson) Date: Wed, 5 Aug 2020 14:40:15 -0600 Subject: [Infrastructure] GitHub streamlining In-Reply-To: References: Message-ID: #1 looks good to me. The SMIME WG discussed using GitHub this morning. During the initial drafting of a document for that WG, it might be good if they had more flexibility in updating the main document (until a final version is ready to be published). On Wed, Aug 5, 2020 at 11:15 AM Ryan Sleevi wrote: > As we transition to GitHub-based workflows for some of our activities, I > was curious if we should start collecting recommended workflows, in > thinking about how permissions, contributions, and reviews should work. > > I've added these to the Infrastructure Project Board > for now, until we can > discuss on our next call. > > # Structure > > Right now, we do everything in github.com/cabforum/documents . On the > Wiki, we segment out activity based on the CWG-level. > > Right now, we have the Forum-wide documents (Bylaws), the SCWG documents > (BRs, EVGs, NSRs), and at least one CSC WG document (br-csc, which is just > a text file). Many other SDOs take the approach of either using a > repository-per-WG or even a repository-per-specification, or a mix of both. > Per our Bylaws, each Final Guideline is the work product of an individual > CWG > > ## Question > We discussed a little on our prior calls, but should we consider: > 1. A separate repository per WG (CWG, FWG)? > 2. A separate repository per Final Guideline? > > I realize the SCWG NetSec Subcommittee has been considering how the NSRs > might integrate in the BRs, and there were previous discussions of folding > the EVGs into the BRs (and, previously, a ballot was held to formally state > we should adopt RFC 3647 format for the EVGs to facilitate that), but > neither of those have happened yet, so #2 might be onerous for the SCWG. > But #1 seems good? > > ## Proposal > If we adopt #1, concretely, this would be my proposed hierarchy: > 1. cabforum/forum > - Contains Bylaws.md, RFC3647_Template.md, SCWG-charter.md, > SCMWG-charter.md > - The charters are placed here since rechartering requires Forum-wide > approval > 2. cabforum/server > - Contains BR.md, EVG.md, NSR.md > 3. cabforum/code_signing > - Contains br-csc > 4. cabforum/smime > - Contains any eventual documents for the S/MIME WG > 5. cabforum/spec-tools > - Avoiding a catchall name like 'infra', this is the set of tools used > to build the specifications (e.g. pandoc, weasyprint, etc) > > > # Permissions > > Independent of whether we adopt the structure suggested above (although > hopefully in concert with it), should we adjust the permissions so that the > relevant Chair/Vice-Chair shall approve changes to the documents? > > Specifically, we can use permissions to create Github teams like > "SCWG-Officers" and "CSC-Officers", which will contain the GitHub IDs of > the Chair and Vice Chair, and require that the officer approve a merge for > the respective documents. > > If we use a single repository, we'd likely accomplish this via CODEOWNERS > > If we use a multiple repository (as above), we could use repository > permissions. > > ## Question > Are there any concerns with going ahead and doing this now, given that > teams are managed at the organization level (i.e. the "cabforum" level), so > we can just use the CODEOWNERs approach until we decide on structure? > > > # IPR Agreement > > As folks know, at the Forum level, we require participation to be > accompanied by the IPR Agreement. This is conceptually similar to a CLA > within open-source. > > It seems like we could use an automated webhook to validate that those > opening PRs (and potentially issues?) have signed the IP Agreement. > > ## Question > Are there concerns with using a tool like > https://colineberhardt.github.io/cla-bot/ to automate verification that > the GitHub user is mapped to a Forum Member or Interested Party and has the > IPR agreement on file? > > Since the IP Agreement is Forum Wide, this would be creating something > like https://github.com/cabforum/cla-config/ (as a private repository) to > track the Forum-wide config, and that'd apply to all of the cabforum/ > Organization, if we go the route of multiple repositories, or it could be > done within cabforum/documents itself. > > > _______________________________________________ > Infrastructure mailing list > Infrastructure at cabforum.org > https://lists.cabforum.org/mailman/listinfo/infrastructure > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwilson at mozilla.com Thu Aug 6 12:17:55 2020 From: bwilson at mozilla.com (Ben Wilson) Date: Thu, 6 Aug 2020 13:17:55 -0600 Subject: [Infrastructure] GitHub Training Message-ID: I definitely think Github training would help. Thanks, Jos. For example, I know how to do a "compare" between the main branch and a proposed ballot when there aren't that many differences between the two. But I ran into trouble today when I tried to do another comparison. See, as example of what an ordinary user like me might encounter: https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d..db4c4af7c01ea815a21bc314fab6cdc4eec7e9f0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Thu Aug 6 15:22:27 2020 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 6 Aug 2020 18:22:27 -0400 Subject: [Infrastructure] GitHub Training In-Reply-To: References: Message-ID: On Thu, Aug 6, 2020 at 3:18 PM Ben Wilson wrote: > I definitely think Github training would help. Thanks, Jos. > For example, I know how to do a "compare" between the main branch and a > proposed ballot when there aren't that many differences between the two. > But I ran into trouble today when I tried to do another comparison. See, > as example of what an ordinary user like me might encounter: > https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d..db4c4af7c01ea815a21bc314fab6cdc4eec7e9f0 > In the meantime, prior to any training, you should be able to find the answer at https://wiki.cabforum.org/github_redline_guide . I believe the cause of your error is addressed at the "2) Your repo is not in sync, and you can automatically merge" section. Indeed, with an extra '.' involved, the differences become a little easier to see: That is, from https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d..db4c4af7c01ea815a21bc314fab6cdc4eec7e9f0 to https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d...db4c4af7c01ea815a21bc314fab6cdc4eec7e9f0 The reason for the difference in displays has to do with the common merge-base: the cabforum/main has added additional changes since you originally created your branch, and so when you do the "two-dot" compare using the cabforum/main repository, it's comparing (everything in cabforum/main since your last branch point) + (everything your branch since your branch point). The "three-dot" compare instead does (everything in your branch since your branch point) - that is, it works to find the "common ancestor" of the commit you specified on the left hand side (the current cabforum/main) and the commit on the right hand side (your branch), and then shows what's different in your branch *from that common ancestor*. This is covered a bit at https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-comparing-branches-in-pull-requests#three-dot-and-two-dot-git-diff-comparisons Normally, if your branch is in sync with cabforum/main, the two-dot compare and the three-dot compare are identical, and that's why our wiki says "use the two-dot compare". That they're different is because of your branch being a few commits "behind" main. If you follow the steps on the wiki, you should get back in sync. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwilson at mozilla.com Thu Aug 6 16:15:05 2020 From: bwilson at mozilla.com (Ben Wilson) Date: Thu, 6 Aug 2020 17:15:05 -0600 Subject: [Infrastructure] GitHub Training In-Reply-To: References: Message-ID: Thanks! So I updated the branches in my repository and it worked. https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d..f4da025a101eb08f2786202458b42520d683ccf9 On Thu, Aug 6, 2020 at 4:23 PM Ryan Sleevi wrote: > > > On Thu, Aug 6, 2020 at 3:18 PM Ben Wilson wrote: > >> I definitely think Github training would help. Thanks, Jos. >> For example, I know how to do a "compare" between the main branch and a >> proposed ballot when there aren't that many differences between the two. >> But I ran into trouble today when I tried to do another comparison. See, >> as example of what an ordinary user like me might encounter: >> https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d..db4c4af7c01ea815a21bc314fab6cdc4eec7e9f0 >> > > In the meantime, prior to any training, you should be able to find the > answer at https://wiki.cabforum.org/github_redline_guide . I believe the > cause of your error is addressed at the "2) Your repo is not in sync, and > you can automatically merge" section. > > Indeed, with an extra '.' involved, the differences become a little > easier to see: That is, from > https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d..db4c4af7c01ea815a21bc314fab6cdc4eec7e9f0 > to > https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d...db4c4af7c01ea815a21bc314fab6cdc4eec7e9f0 > > The reason for the difference in displays has to do with the common > merge-base: the cabforum/main has added additional changes since you > originally created your branch, and so when you do the "two-dot" compare > using the cabforum/main repository, it's comparing (everything in > cabforum/main since your last branch point) + (everything your branch since > your branch point). The "three-dot" compare instead does (everything in > your branch since your branch point) - that is, it works to find the > "common ancestor" of the commit you specified on the left hand side (the > current cabforum/main) and the commit on the right hand side (your branch), > and then shows what's different in your branch *from that common ancestor*. > This is covered a bit at > https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-comparing-branches-in-pull-requests#three-dot-and-two-dot-git-diff-comparisons > > Normally, if your branch is in sync with cabforum/main, the two-dot > compare and the three-dot compare are identical, and that's why our wiki > says "use the two-dot compare". That they're different is because of your > branch being a few commits "behind" main. If you follow the steps on the > wiki, you should get back in sync. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jopurvis at cisco.com Wed Aug 12 08:10:57 2020 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Wed, 12 Aug 2020 15:10:57 +0000 Subject: [Infrastructure] Different meeting link today Message-ID: Webex is being annoying, so we?ll use my space just for today?s meeting: ??????????? https://cisco.webex.com/meet/jopurvis Sorry for the issues! -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls and Trust Verification -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3699 bytes Desc: not available URL: From dzacharo at harica.gr Thu Aug 20 08:56:09 2020 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Thu, 20 Aug 2020 18:56:09 +0300 Subject: [Infrastructure] GitHub unintended consequences and triggering artifact generation Message-ID: I followed https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chairactions_after_the_ipr_review_period for SC30 and SC31 based on the existing pull request and review (https://github.com/cabforum/documents/pull/203). The process had a step to delete the temporary branch (Ballot-SC30-and-31), which I did. Unfortunately, this also closed https://github.com/cabforum/documents/pull/207 because it was depending on the temporary branch Ballot-SC30-and-31. Ryan, is this something you can fix? We should probably update the instructions accordingly. I also went to download the artifacts (https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/main/BR.docx) after the merge, but they were not updated according to the last commits. I assume that the artifacts are created the first time you create the pull request and not when you add commits to that pull request afterwards. Is that correct? What would be the best way to generate these artifacts now? We probably need to update the workflow to include steps to create the artifacts after the last merge. Thanks, Dimitris. From sleevi at google.com Thu Aug 20 11:07:00 2020 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 20 Aug 2020 14:07:00 -0400 Subject: [Infrastructure] GitHub unintended consequences and triggering artifact generation In-Reply-To: References: Message-ID: On Thu, Aug 20, 2020 at 11:56 AM Dimitris Zacharopoulos (HARICA) < dzacharo at harica.gr> wrote: > > I followed > > https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chairactions_after_the_ipr_review_period > for SC30 and SC31 based on the existing pull request and review > (https://github.com/cabforum/documents/pull/203). The process had a step to delete the temporary branch > (Ballot-SC30-and-31), which I did. Unfortunately, this also closed > https://github.com/cabforum/documents/pull/207 because it was depending > on the temporary branch Ballot-SC30-and-31. > > Ryan, is this something you can fix? Yes, it's no big deal and what I expected to happen. > We should probably update the > instructions accordingly. > For what? I used a non-standard approach that intentionally isn't documented to begin with ;-) I think we likely want to focus our documentation on common, normal flows intended for those not wanting to learn Git or GitHub (totally understandable) or the Chair and Vice-Chair to produce results, and don't need to try to document every scenario or use case. Weird edge cases (like where I've created multiple branches to show in-progress stuff) is something I think we can and should deal with on an ad-hoc basis, because it's rare, exceptional, and trying to document all the edge cases just introduces more room for failure. > I also went to download the artifacts > ( > https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/main/BR.docx) > > after the merge, but they were not updated according to the last > commits. I assume that the artifacts are created the first time you > create the pull request and not when you add commits to that pull > request afterwards. Is that correct? > No. The artifacts are generated for every commit. It's not clear to me what you're describing, so hopefully you can clarify. The URL you linked is only updated after you merge the commit. If you want to view commits as you add them to the PR, before it is merged, the link is to the branch name - e.g. https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/Ballot-SC30-and-31/BR.docx If you added commits to the branch after you merged, and did not merge those, don't do that, that's not part of any documented instruction :) > What would be the best way to generate these artifacts now? We probably > need to update the workflow to include steps to create the artifacts > after the last merge. > Doubtful! It's probably just that you didn't let the update process complete :) https://travis-ci.org/github/cabforum/documents/builds/719653438 shows it took 2 minutes and 6 seconds to generate the artifacts. Did you try to view immediately after committing, and before 2 minutes and 6 seconds had passed? This is one of those things that is in the file of "improvements to consider" (switching to GitHub actions , so it adds the UI signals). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzacharo at harica.gr Fri Aug 21 02:10:12 2020 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Fri, 21 Aug 2020 12:10:12 +0300 Subject: [Infrastructure] GitHub unintended consequences and triggering artifact generation In-Reply-To: References: Message-ID: <5508965a-4fb1-7bbd-170d-ab457dca40bb@harica.gr> On 20/8/2020 9:07 ?.?., Ryan Sleevi wrote: > > > On Thu, Aug 20, 2020 at 11:56 AM Dimitris Zacharopoulos (HARICA) > > wrote: > > > I followed > https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chairactions_after_the_ipr_review_period > > for SC30 and SC31 based on the existing pull request and review > (https://github.com/cabforum/documents/pull/203). > > The process had a step to delete the temporary branch > (Ballot-SC30-and-31), which I did. Unfortunately, this also closed > https://github.com/cabforum/documents/pull/207 because it was > depending > on the temporary branch Ballot-SC30-and-31. > > Ryan, is this something you can fix? > > > Yes, it's no big deal and what I expected to happen. > > We should probably update the > instructions accordingly. > > > For what? I used a non-standard approach that intentionally isn't > documented to begin with ;-) No objections to this approach. What I meant by "update the instructions" was more of adding a "hint" to ballot proposers with language on how to avoid such situations (e.g. "Use separate branches for follow-up ballots..." or "don't create new ballots on branches that are used for PR against the main cabforum/documents branch"). I didn't intend to change the existing workflow if it wasn't necessary. You might be perfectly familiar with how Git repos work and interact with each other, but another ballot proposer might get confused :) > > I think we likely want to focus our documentation on common, normal > flows intended for those not wanting to learn Git or GitHub (totally > understandable) or the Chair and Vice-Chair to produce results, and > don't need to try to document every scenario or use case. Weird edge > cases (like where I've created multiple branches to show in-progress > stuff) is something I think we can and should deal with on an ad-hoc > basis, because it's rare, exceptional, and trying to document all the > edge cases just introduces more room for failure. I agree. > > I also went to download the artifacts > (https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/main/BR.docx) > > after the merge, but they were not updated according to the last > commits. I assume that the artifacts are created the first time you > create the pull request and not when you add commits to that pull > request afterwards. Is that correct? > > > No. The artifacts are generated for every commit. > > It's not clear to me what you're describing, so hopefully you can > clarify. The URL you linked is only updated after you merge the commit. I merged the commit and waited a few minutes before downloading the docx artifact, but the document was old. > If you want to view commits as you add them to the PR, before it is > merged, the link is to the branch name - e.g. > https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/Ballot-SC30-and-31/BR.docx > > If you added commits to the branch after you merged, and did not merge > those, don't do that, that's not part of any documented instruction :) This practice is avoided, and I believe we have configured the repo to technically forbid that (i.e. require at least a review by a second repo maintainer before merge to main is allowed). > What would be the best way to generate these artifacts now? We > probably > need to update the workflow to include steps to create the artifacts > after the last merge. > > > Doubtful! It's probably just that you didn't let the update process > complete :) > > https://travis-ci.org/github/cabforum/documents/builds/719653438 shows > it took 2 minutes and 6 seconds to generate the artifacts. Did you try > to view immediately after committing, and before 2 minutes and 6 > seconds had passed? > > This is one of those things that is in the file of "improvements to > consider" (switching to GitHub actions > , so > it adds the UI signals). I could almost swear that I waited more than 2 minutes and 6 seconds before trying to download the artifacts, but apparently I didn't :-) Next time I will be more patient and wait, until we manage to have UI signals for the CI. Thanks, Dimitris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Fri Aug 21 08:30:24 2020 From: sleevi at google.com (Ryan Sleevi) Date: Fri, 21 Aug 2020 11:30:24 -0400 Subject: [Infrastructure] GitHub unintended consequences and triggering artifact generation In-Reply-To: <5508965a-4fb1-7bbd-170d-ab457dca40bb@harica.gr> References: <5508965a-4fb1-7bbd-170d-ab457dca40bb@harica.gr> Message-ID: On Fri, Aug 21, 2020 at 5:10 AM Dimitris Zacharopoulos (HARICA) < dzacharo at harica.gr> wrote: > > > On 20/8/2020 9:07 ?.?., Ryan Sleevi wrote: > > > > On Thu, Aug 20, 2020 at 11:56 AM Dimitris Zacharopoulos (HARICA) < > dzacharo at harica.gr> wrote: > >> >> I followed >> >> https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chairactions_after_the_ipr_review_period >> for SC30 and SC31 based on the existing pull request and review >> (https://github.com/cabforum/documents/pull/203). > > > > The process had a step to delete the temporary branch >> (Ballot-SC30-and-31), which I did. Unfortunately, this also closed >> https://github.com/cabforum/documents/pull/207 because it was depending >> on the temporary branch Ballot-SC30-and-31. >> >> Ryan, is this something you can fix? > > > Yes, it's no big deal and what I expected to happen. > > >> We should probably update the >> instructions accordingly. >> > > For what? I used a non-standard approach that intentionally isn't > documented to begin with ;-) > > > No objections to this approach. What I meant by "update the instructions" > was more of adding a "hint" to ballot proposers with language on how to > avoid such situations (e.g. "Use separate branches for follow-up > ballots..." or "don't create new ballots on branches that are used for PR > against the main cabforum/documents branch"). I didn't intend to change the > existing workflow if it wasn't necessary. You might be perfectly familiar > with how Git repos work and interact with each other, but another ballot > proposer might get confused :) > > > I think we likely want to focus our documentation on common, normal flows > intended for those not wanting to learn Git or GitHub (totally > understandable) or the Chair and Vice-Chair to produce results, and don't > need to try to document every scenario or use case. Weird edge cases (like > where I've created multiple branches to show in-progress stuff) is > something I think we can and should deal with on an ad-hoc basis, because > it's rare, exceptional, and trying to document all the edge cases just > introduces more room for failure. > > > I agree. > > > >> I also went to download the artifacts >> ( >> https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/main/BR.docx) >> >> after the merge, but they were not updated according to the last >> commits. I assume that the artifacts are created the first time you >> create the pull request and not when you add commits to that pull >> request afterwards. Is that correct? >> > > No. The artifacts are generated for every commit. > > It's not clear to me what you're describing, so hopefully you can clarify. > The URL you linked is only updated after you merge the commit. > > > I merged the commit and waited a few minutes before downloading the docx > artifact, but the document was old. > > If you want to view commits as you add them to the PR, before it is > merged, the link is to the branch name - e.g. > https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/Ballot-SC30-and-31/BR.docx > > If you added commits to the branch after you merged, and did not merge > those, don't do that, that's not part of any documented instruction :) > > > This practice is avoided, and I believe we have configured the repo to > technically forbid that (i.e. require at least a review by a second repo > maintainer before merge to main is allowed). > > > >> What would be the best way to generate these artifacts now? We probably >> need to update the workflow to include steps to create the artifacts >> after the last merge. >> > > Doubtful! It's probably just that you didn't let the update process > complete :) > > https://travis-ci.org/github/cabforum/documents/builds/719653438 shows it > took 2 minutes and 6 seconds to generate the artifacts. Did you try to view > immediately after committing, and before 2 minutes and 6 seconds had passed? > > This is one of those things that is in the file of "improvements to > consider" (switching to GitHub actions > , so it > adds the UI signals). > > > I could almost swear that I waited more than 2 minutes and 6 seconds > before trying to download the artifacts, but apparently I didn't :-) > > Next time I will be more patient and wait, until we manage to have UI > signals for the CI. > Right now, https://travis-ci.org/github/cabforum/documents/builds/ But I almost hesitate to document that, because I'd like to fix that "real soon" (modulo time commitments), since the GitHub Actions would let you view it directly (as an attached artifact) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Fri Aug 21 08:31:52 2020 From: sleevi at google.com (Ryan Sleevi) Date: Fri, 21 Aug 2020 11:31:52 -0400 Subject: [Infrastructure] GitHub unintended consequences and triggering artifact generation In-Reply-To: References: <5508965a-4fb1-7bbd-170d-ab457dca40bb@harica.gr> Message-ID: On Fri, Aug 21, 2020 at 11:30 AM Ryan Sleevi wrote: > > > On Fri, Aug 21, 2020 at 5:10 AM Dimitris Zacharopoulos (HARICA) < > dzacharo at harica.gr> wrote: > >> >> >> On 20/8/2020 9:07 ?.?., Ryan Sleevi wrote: >> >> >> >> On Thu, Aug 20, 2020 at 11:56 AM Dimitris Zacharopoulos (HARICA) < >> dzacharo at harica.gr> wrote: >> >>> >>> I followed >>> >>> https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chairactions_after_the_ipr_review_period >>> for SC30 and SC31 based on the existing pull request and review >>> (https://github.com/cabforum/documents/pull/203). >> >> >> >> The process had a step to delete the temporary branch >>> (Ballot-SC30-and-31), which I did. Unfortunately, this also closed >>> https://github.com/cabforum/documents/pull/207 because it was depending >>> on the temporary branch Ballot-SC30-and-31. >>> >>> Ryan, is this something you can fix? >> >> >> Yes, it's no big deal and what I expected to happen. >> >> >>> We should probably update the >>> instructions accordingly. >>> >> >> For what? I used a non-standard approach that intentionally isn't >> documented to begin with ;-) >> >> >> No objections to this approach. What I meant by "update the instructions" >> was more of adding a "hint" to ballot proposers with language on how to >> avoid such situations (e.g. "Use separate branches for follow-up >> ballots..." or "don't create new ballots on branches that are used for PR >> against the main cabforum/documents branch"). I didn't intend to change the >> existing workflow if it wasn't necessary. You might be perfectly familiar >> with how Git repos work and interact with each other, but another ballot >> proposer might get confused :) >> >> >> I think we likely want to focus our documentation on common, normal flows >> intended for those not wanting to learn Git or GitHub (totally >> understandable) or the Chair and Vice-Chair to produce results, and don't >> need to try to document every scenario or use case. Weird edge cases (like >> where I've created multiple branches to show in-progress stuff) is >> something I think we can and should deal with on an ad-hoc basis, because >> it's rare, exceptional, and trying to document all the edge cases just >> introduces more room for failure. >> >> >> I agree. >> >> >> >>> I also went to download the artifacts >>> ( >>> https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/main/BR.docx) >>> >>> after the merge, but they were not updated according to the last >>> commits. I assume that the artifacts are created the first time you >>> create the pull request and not when you add commits to that pull >>> request afterwards. Is that correct? >>> >> >> No. The artifacts are generated for every commit. >> >> It's not clear to me what you're describing, so hopefully you can >> clarify. The URL you linked is only updated after you merge the commit. >> >> >> I merged the commit and waited a few minutes before downloading the docx >> artifact, but the document was old. >> >> If you want to view commits as you add them to the PR, before it is >> merged, the link is to the branch name - e.g. >> https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/Ballot-SC30-and-31/BR.docx >> >> If you added commits to the branch after you merged, and did not merge >> those, don't do that, that's not part of any documented instruction :) >> >> >> This practice is avoided, and I believe we have configured the repo to >> technically forbid that (i.e. require at least a review by a second repo >> maintainer before merge to main is allowed). >> >> >> >>> What would be the best way to generate these artifacts now? We probably >>> need to update the workflow to include steps to create the artifacts >>> after the last merge. >>> >> >> Doubtful! It's probably just that you didn't let the update process >> complete :) >> >> https://travis-ci.org/github/cabforum/documents/builds/719653438 shows >> it took 2 minutes and 6 seconds to generate the artifacts. Did you try to >> view immediately after committing, and before 2 minutes and 6 seconds had >> passed? >> >> This is one of those things that is in the file of "improvements to >> consider" (switching to GitHub actions >> , so it >> adds the UI signals). >> >> >> I could almost swear that I waited more than 2 minutes and 6 seconds >> before trying to download the artifacts, but apparently I didn't :-) >> >> Next time I will be more patient and wait, until we manage to have UI >> signals for the CI. >> > > Right now, https://travis-ci.org/github/cabforum/documents/builds/ > > But I almost hesitate to document that, because I'd like to fix that "real > soon" (modulo time commitments), since the GitHub Actions would let you > view it directly (as an attached artifact) > Oh, and I suppose one bit I should have clarified: you don't need to run the build after the merge. If your branch is mergable and in sync, the branch's copy of the document is going to be identical to the main repo. So just grab the copy from the PR branch, which does have UI signals already (which also shows the CI status as failing, running, or successful per-commit) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzacharo at harica.gr Mon Aug 24 03:21:03 2020 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Mon, 24 Aug 2020 13:21:03 +0300 Subject: [Infrastructure] GitHub unintended consequences and triggering artifact generation In-Reply-To: References: <5508965a-4fb1-7bbd-170d-ab457dca40bb@harica.gr> Message-ID: <0fc0a266-71e1-7d78-67dc-2a0a9576f8ca@harica.gr> This is really helpful, thanks! If anyone can find the time, it would be great to have some quick instructions on how to add "tags" on GitHub using the web UI. I could even use the local git CLI if it's easier to do that. I believe the end goal is to add version tags for each produced Final Guideline. DZ. On 21/8/2020 6:31 ?.?., Ryan Sleevi wrote: > > > On Fri, Aug 21, 2020 at 11:30 AM Ryan Sleevi > wrote: > > > > On Fri, Aug 21, 2020 at 5:10 AM Dimitris Zacharopoulos (HARICA) > > wrote: > > > > On 20/8/2020 9:07 ?.?., Ryan Sleevi wrote: >> >> >> On Thu, Aug 20, 2020 at 11:56 AM Dimitris Zacharopoulos >> (HARICA) > wrote: >> >> >> I followed >> https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chairactions_after_the_ipr_review_period >> >> for SC30 and SC31 based on the existing pull request and >> review >> (https://github.com/cabforum/documents/pull/203). >> >> The process had a step to delete the temporary branch >> (Ballot-SC30-and-31), which I did. Unfortunately, this >> also closed >> https://github.com/cabforum/documents/pull/207 because it >> was depending >> on the temporary branch Ballot-SC30-and-31. >> >> Ryan, is this something you can fix? >> >> >> Yes, it's no big deal and what I expected to happen. >> >> We should probably update the >> instructions accordingly. >> >> >> For what? I used a non-standard approach that intentionally >> isn't documented to begin with ;-) > > No objections to this approach. What I meant by "update the > instructions" was more of adding a "hint" to ballot proposers > with language on how to avoid such situations (e.g. "Use > separate branches for follow-up ballots..." or "don't create > new ballots on branches that are used for PR against the main > cabforum/documents branch"). I didn't intend to change the > existing workflow if it wasn't necessary. You might be > perfectly familiar with how Git repos work and interact with > each other, but another ballot proposer might get confused :) > >> >> I think we likely want to focus our documentation on common, >> normal flows intended for those not wanting to learn Git or >> GitHub (totally understandable) or the Chair and Vice-Chair >> to produce results, and don't need to try to document every >> scenario or use case. Weird edge cases (like where I've >> created multiple branches to show in-progress stuff) is >> something I think we can and should deal with on an ad-hoc >> basis, because it's rare, exceptional, and trying to document >> all the edge cases just introduces more room for failure. > > I agree. >> >> I also went to download the artifacts >> (https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/main/BR.docx) >> >> after the merge, but they were not updated according to >> the last >> commits. I assume that the artifacts are created the >> first time you >> create the pull request and not when you add commits to >> that pull >> request afterwards. Is that correct? >> >> >> No. The artifacts are generated for every commit. >> >> It's not clear to me what you're describing, so hopefully you >> can clarify. The URL you linked is only updated after you >> merge the commit. > > I merged the commit and waited a few minutes before > downloading the docx artifact, but the document was old. > >> If you want to view commits as you add them to the PR, before >> it is merged, the link is to the branch name - e.g. >> https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com/builds/Ballot-SC30-and-31/BR.docx >> >> If you added commits to the branch after you merged, and did >> not merge those, don't do that, that's not part of any >> documented instruction :) > > This practice is avoided, and I believe we have configured the > repo to technically forbid that (i.e. require at least a > review by a second repo maintainer before merge to main is > allowed). > >> What would be the best way to generate these artifacts >> now? We probably >> need to update the workflow to include steps to create >> the artifacts >> after the last merge. >> >> >> Doubtful! It's probably just that you didn't let the update >> process complete :) >> >> https://travis-ci.org/github/cabforum/documents/builds/719653438 >> shows it took 2 minutes and 6 seconds to generate the >> artifacts. Did you try to view immediately after committing, >> and before 2 minutes and 6 seconds had passed? >> >> This is one of those things that is in the file of >> "improvements to consider" (switching to GitHub actions >> , >> so it adds the UI signals). > > I could almost swear that I waited more than 2 minutes and 6 > seconds before trying to download the artifacts, but > apparently I didn't :-) > > Next time I will be more patient and wait, until we manage to > have UI signals for the CI. > > > Right now, https://travis-ci.org/github/cabforum/documents/builds/ > > But I almost hesitate to document that, because I'd like to fix > that "real soon" (modulo time commitments), since the GitHub > Actions would let you view it directly (as an attached artifact) > > > Oh, and I suppose one bit I should have clarified: you don't need to > run the build after the merge. If your branch is mergable and in sync, > the branch's copy of the document is going to be identical to the main > repo. So just grab the copy from the PR branch, which does have UI > signals already (which also shows the CI status as failing, running, > or successful per-commit) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jopurvis at cisco.com Wed Aug 26 06:40:52 2020 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Wed, 26 Aug 2020 13:40:52 +0000 Subject: [Infrastructure] Meeting issues today Message-ID: <53987DF2-A663-4F0D-958D-1E479BEF4724@cisco.com> Hi folks, I'm still having an issue with my CABF Webex account (the removal of the old account seems to have taken my hosting privileges with it). I have a case open with Webex to fix it (hopefully!), but I'll need someone else with a host account to start the meeting today. Alternately, if there's not a lot to discuss we can finesse the meeting today and continue working on clearing out to-dos. -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls & Trust Verification -------------- next part -------------- An HTML attachment was scrubbed... URL: From wthayer at gmail.com Wed Aug 26 08:03:49 2020 From: wthayer at gmail.com (Wayne Thayer) Date: Wed, 26 Aug 2020 08:03:49 -0700 Subject: [Infrastructure] Meeting issues today In-Reply-To: <53987DF2-A663-4F0D-958D-1E479BEF4724@cisco.com> References: <53987DF2-A663-4F0D-958D-1E479BEF4724@cisco.com> Message-ID: Jos - I tried to start the meeting but Webex is throwing the same generic error message we saw last time. I'm guessing it's related to the problem with your account. On Wed, Aug 26, 2020 at 6:41 AM Jos Purvis (jopurvis) wrote: > Hi folks, > > > > I'm still having an issue with my CABF Webex account (the removal of the > old account seems to have taken my hosting privileges with it). I have a > case open with Webex to fix it (hopefully!), but I'll need someone else > with a host account to start the meeting today. Alternately, if there's not > a lot to discuss we can finesse the meeting today and continue working on > clearing out to-dos. > > > > -- > Jos Purvis (jopurvis at cisco.com) > .:|:.:|:. cisco systems | Cryptographic Services > PGP: 0xFD802FEE07D19105 | Controls & Trust Verification > > > _______________________________________________ > Infrastructure mailing list > Infrastructure at cabforum.org > https://lists.cabforum.org/mailman/listinfo/infrastructure > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jopurvis at cisco.com Wed Aug 26 08:05:03 2020 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Wed, 26 Aug 2020 15:05:03 +0000 Subject: [Infrastructure] Meeting issues today In-Reply-To: References: <53987DF2-A663-4F0D-958D-1E479BEF4724@cisco.com> Message-ID: <31102047-126F-4525-AB7E-32640B21B88F@cisco.com> Fair enough. For today, let?s use my account to meet: https://cisco.webex.com/meet/jopurvis Webex is working on the issue; hopefully they?ll have it solved today. -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls and Trust Verification From: Wayne Thayer Date: Wednesday, August 26, 2020 at 11:04 AM To: "Jos Purvis (jopurvis)" Cc: "infrastructure at cabforum.org" Subject: Re: [Infrastructure] Meeting issues today Jos - I tried to start the meeting but Webex is throwing the same generic error message we saw last time. I'm guessing it's related to the problem with your account. On Wed, Aug 26, 2020 at 6:41 AM Jos Purvis (jopurvis) wrote: Hi folks, I'm still having an issue with my CABF Webex account (the removal of the old account seems to have taken my hosting privileges with it). I have a case open with Webex to fix it (hopefully!), but I'll need someone else with a host account to start the meeting today. Alternately, if there's not a lot to discuss we can finesse the meeting today and continue working on clearing out to-dos. -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls & Trust Verification _______________________________________________ Infrastructure mailing list Infrastructure at cabforum.org https://lists.cabforum.org/mailman/listinfo/infrastructure -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3699 bytes Desc: not available URL: From wthayer at gmail.com Mon Aug 31 09:16:13 2020 From: wthayer at gmail.com (Wayne Thayer) Date: Mon, 31 Aug 2020 09:16:13 -0700 Subject: [Infrastructure] Separate GitHub Repositories for Each Working Group Message-ID: 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. 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 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). Each repo will be configured to enforce reviews before merging a pull request. This change will be accomplished by moving documents from the existing repo into the new ones in such a way that history is preserved (most likely by forking 'documents' and then deleting files that are not in the scope of the new repo). The change will be made on XX date. ================ What am I missing? Thanks, Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Mon Aug 31 09:31:52 2020 From: sleevi at google.com (Ryan Sleevi) Date: Mon, 31 Aug 2020 12:31:52 -0400 Subject: [Infrastructure] Separate GitHub Repositories for Each Working Group In-Reply-To: References: Message-ID: On Mon, Aug 31, 2020 at 12:16 PM Wayne Thayer 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. > 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. 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. > 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). > One area that hadn't been worked through is whether or not the Forum Infrastructure group (or some subset) will be admins for these repositories or not? That has implications here for the statement of permissions, but also has implications when we thinking about how publishing will work (e.g. shared secrets in the repo config) > Each repo will be configured to enforce reviews before merging a pull > request. > ... into the "main" repository, right? > This change will be accomplished by moving documents from the existing > repo into the new ones in such a way that history is preserved (most likely > by forking 'documents' and then deleting files that are not in the scope of > the new repo). > This seems like it's gated on the completion of branch cleanup, right, so that we don't bring in a ton of junk into new repos? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wthayer at gmail.com Mon Aug 31 09:46:33 2020 From: wthayer at gmail.com (Wayne Thayer) Date: Mon, 31 Aug 2020 09:46:33 -0700 Subject: [Infrastructure] Separate GitHub Repositories for Each Working Group In-Reply-To: References: Message-ID: Thanks Ryan - this is helpful. On Mon, Aug 31, 2020 at 9:32 AM Ryan Sleevi wrote: > > > On Mon, Aug 31, 2020 at 12:16 PM Wayne Thayer 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. > > 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. 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). >> > > One area that hadn't been worked through is whether or not the Forum > Infrastructure group (or some subset) will be admins for these repositories > or not? That has implications here for the statement of permissions, but > also has implications when we thinking about how publishing will work (e.g. > shared secrets in the repo config) > > Suggest we discuss this on the next call. Each repo will be configured to enforce reviews before merging a pull >> request. >> > > ... into the "main" repository, right? > > Correct. This change will be accomplished by moving documents from the existing repo >> into the new ones in such a way that history is preserved (most likely by >> forking 'documents' and then deleting files that are not in the scope of >> the new repo). >> > > This seems like it's gated on the completion of branch cleanup, right, so > that we don't bring in a ton of junk into new repos? > That seems like a good idea. We should discuss the cleanup on the next call. - Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: