From rsalz at akamai.com Thu Oct 3 13:39:02 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 3 Oct 2019 13:39:02 +0000 Subject: UK or US spelling in manages? Message-ID: <730245EF-C3F4-4279-8CA6-426FFDBC9827@akamai.com> OpenSSL is in the final stages of a *massive* cleanup of the manpages. Many of them are nit-level things, bringing them into conformance with common style, as expressed at http://man7.org/linux/man-pages/man7/man-pages.7.html There is on notable difference: openssl uses a mix of UK and US spelling ? favouring initialize and such instead of favoring initialize and such. Most manpages, and the link above, recommend US spelling. You can see the start of a discussion on this at https://github.com/openssl/openssl/pull/10079 While I respect the Commonwealth?s impact on SSLeay and OpenSSL :), I believe the right thing is to follow US style as everyone else does. I am asking the OMC to discuss, decide, and vote on a policy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Fri Oct 4 07:15:53 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 4 Oct 2019 07:15:53 +0000 Subject: Commit access to openssl/tools and openssl/web Message-ID: Dear OMC, while the process of merging and committing to openssl/openssl has been formalized, no similar (official) rules for pull requests by non-OMC-member seem to apply to the other two repositories openssl/tools and openssl/web. Probably it's because hardly anybody outside the OMC else ever raises them? Or is it the other way around? I would like to raise the question whether it wouldn't be beneficial for all of us, if we would apply the same rules (commit access for all committers, plus the well known approval rules) to all of our repos. After all, the openssl/openssl repository is the most valuable of the three and I see no reason why the others would need more protection. In the case of the openssl/web repository which targets the official website, you might want to consider a 2OMC approval rule, but even there I don't see why the usual OMC veto rule wouldn't be sufficient. Regards, Matthias From matt at openssl.org Fri Oct 4 07:39:33 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 4 Oct 2019 08:39:33 +0100 Subject: Commit access to openssl/tools and openssl/web In-Reply-To: References: Message-ID: On 04/10/2019 08:15, Dr. Matthias St. Pierre wrote: > Dear OMC, > > while the process of merging and committing to openssl/openssl has been formalized, > no similar (official) rules for pull requests by non-OMC-member seem to apply to the > other two repositories openssl/tools and openssl/web. Probably it's because hardly > anybody outside the OMC else ever raises them? Or is it the other way around? There are clear official rules. This vote was passed by the OMC over a year ago: topic: Openssl-web and tools repositories shall be under the same review policy as per the openssl repository where the reviewers are OMC members So it needs two approvals from an OMC member. It looks like recent commits haven't obeyed those rules. > I would like to raise the question whether it wouldn't be beneficial for all of us, > if we would apply the same rules (commit access for all committers, plus the well > known approval rules) to all of our repos. After all, the openssl/openssl repository > is the most valuable of the three and I see no reason why the others would need > more protection. In the case of the openssl/web repository which targets the > official website, you might want to consider a 2OMC approval rule, but even there > I don't see why the usual OMC veto rule wouldn't be sufficient. There is a lot of merit in that. Certainly for tools. I've added it to the OMC agenda for Nuremburg. Matt From paul.dale at oracle.com Fri Oct 4 07:49:58 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 4 Oct 2019 17:49:58 +1000 Subject: Commit access to openssl/tools and openssl/web In-Reply-To: References: Message-ID: <2E2D0FA2-B02C-4228-87DA-1924FF754D33@oracle.com> I believed that it required two OMC approvals but was pointed to an earlier instance where only one was present and I flew with it without checking further. My apologies for merging prematurely and I?ll back out the changes if any OMC member wants. As for discussing this at the upcoming face to face, I agree wholeheartedly. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 4 Oct 2019, at 5:39 pm, Matt Caswell wrote: > > > > On 04/10/2019 08:15, Dr. Matthias St. Pierre wrote: >> Dear OMC, >> >> while the process of merging and committing to openssl/openssl has been formalized, >> no similar (official) rules for pull requests by non-OMC-member seem to apply to the >> other two repositories openssl/tools and openssl/web. Probably it's because hardly >> anybody outside the OMC else ever raises them? Or is it the other way around? > > There are clear official rules. This vote was passed by the OMC over a year ago: > > topic: Openssl-web and tools repositories shall be under the same review > policy as per the openssl repository where the reviewers are OMC members > > So it needs two approvals from an OMC member. It looks like recent commits > haven't obeyed those rules. > > >> I would like to raise the question whether it wouldn't be beneficial for all of us, >> if we would apply the same rules (commit access for all committers, plus the well >> known approval rules) to all of our repos. After all, the openssl/openssl repository >> is the most valuable of the three and I see no reason why the others would need >> more protection. In the case of the openssl/web repository which targets the >> official website, you might want to consider a 2OMC approval rule, but even there >> I don't see why the usual OMC veto rule wouldn't be sufficient. > > There is a lot of merit in that. Certainly for tools. I've added it to the OMC > agenda for Nuremburg. > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Fri Oct 4 07:51:28 2019 From: tjh at cryptsoft.com (Tim Hudson) Date: Fri, 4 Oct 2019 17:51:28 +1000 Subject: Commit access to openssl/tools and openssl/web In-Reply-To: <2E2D0FA2-B02C-4228-87DA-1924FF754D33@oracle.com> References: <2E2D0FA2-B02C-4228-87DA-1924FF754D33@oracle.com> Message-ID: FYI - I have reviewed and added my approval. No need to back out anything. Tim. On Fri, Oct 4, 2019 at 5:50 PM Dr Paul Dale wrote: > I believed that it required two OMC approvals but was pointed to an > earlier instance where only one was present and I flew with it without > checking further. > My apologies for merging prematurely and I?ll back out the changes if any > OMC member wants. > > As for discussing this at the upcoming face to face, I agree > wholeheartedly. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 4 Oct 2019, at 5:39 pm, Matt Caswell wrote: > > > > On 04/10/2019 08:15, Dr. Matthias St. Pierre wrote: > > Dear OMC, > > while the process of merging and committing to openssl/openssl has been > formalized, > no similar (official) rules for pull requests by non-OMC-member seem to > apply to the > other two repositories openssl/tools and openssl/web. Probably it's > because hardly > anybody outside the OMC else ever raises them? Or is it the other way > around? > > > There are clear official rules. This vote was passed by the OMC over a > year ago: > > topic: Openssl-web and tools repositories shall be under the same review > policy as per the openssl repository where the reviewers are OMC > members > > So it needs two approvals from an OMC member. It looks like recent commits > haven't obeyed those rules. > > > I would like to raise the question whether it wouldn't be beneficial for > all of us, > if we would apply the same rules (commit access for all committers, plus > the well > known approval rules) to all of our repos. After all, the openssl/openssl > repository > is the most valuable of the three and I see no reason why the others would > need > more protection. In the case of the openssl/web repository which targets > the > official website, you might want to consider a 2OMC approval rule, but > even there > I don't see why the usual OMC veto rule wouldn't be sufficient. > > > There is a lot of merit in that. Certainly for tools. I've added it to the > OMC > agenda for Nuremburg. > > Matt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Oct 7 09:30:39 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 7 Oct 2019 10:30:39 +0100 Subject: Monthly Status Report (September) Message-ID: <9c412991-abff-7a62-0968-93804b88d1c1@openssl.org> As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Implemented the ability for providers to perform signature operations and moved DSA to the default provider - Performed the release of 1.1.1d, 1.1.0l and 1.0.2t - Fixed an issue where a non-empty status_request extension was being sent in a CertificateRequest message - Investigated a failure when calling DH_check() in the pyca cryptography external tests - Fixed no-dsa - Fixed no-engine - Fixed an asan failure due to an incorrect value being passed to provider KDF functions - Fixed undefined behaviour where NULL was passed to memcpy - Made proposals for fixing the issue around FIPS self-test being triggered multiple times - Fixed an issue where EVP_MD_CTX_[gettable|settable]_params, did not actually take an EVP_MD_CTX as a parameter - Implemented PR for DigestSign/DigestVerify support in providers - Fixed documentation for stateless cookie callbacks, and added documentation for DTLSv1_listen() cookie callbacks Matt From rsalz at akamai.com Mon Oct 21 19:00:30 2019 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 21 Oct 2019 19:00:30 +0000 Subject: FW: Interview participation request In-Reply-To: References: Message-ID: <25865087-2C51-47F2-836C-420435279838@akamai.com> Folks, I did a Skype call with James. You might want to let him talk to you so that it?s more than just my view :) It was fun. He?s done a lot of number-crunching of OpenSSL through the years, including things like complexity (depth of nesting) and such. Maybe you can do a group-chat during your F2F? At any rate I encourage you to talk with him. From: James Walden Date: Monday, October 21, 2019 at 2:58 PM To: Rich Salz Subject: Interview participation request I am writing to ask if you would agree to be interviewed online for a research project titled "The Evolution of OpenSSL after Heartbleed." This study aims to identify software engineering practices and technologies that have helped project members improve the security and quality of OpenSSL code in the five years since the discovery of the Heartbleed vulnerability. If you agree to participate, I will interview you for an hour or less via an audio conferencing tool, such as Skype. During the interview, I will ask questions about your role in the project and about project activities, such as code review of potential commits. Interviewees may participate anonymously or give permission to be quoted in the resulting paper. All participants will be given an opportunity to review the research paper for correctness prior to publication. Can I contact you to set up a time for an interview? Thank you for your consideration, James Walden, Ph.D. Department of Computer Science Northern Kentucky University Highland Heights, KY 41099 email: waldenj1 at nku.edu phone: 859-572-5571 web: https://faculty.cs.nku.edu/~waldenj/ James Walden, Ph.D. - faculty.cs.nku.edu Research: Secure Software Engineering, Security Metrics, Web Application Security, Machine Learning and Software Engineering faculty.cs.nku.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Sat Oct 26 13:40:22 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 26 Oct 2019 13:40:22 +0000 Subject: New GitHub labels for pull request and issues - 24 hour grace period Message-ID: <9a62f1112db648f6b01fd5356493a084@Ex13.ncp.local> Hi all, some of you contributors might have already noticed that the labels which are attached to the GitHub pull requests and issues have changed. During the face to face meeting it was decided to cleanup some of the unused labels and to organize the labelling more systematically to match our review and merging process. The following gives you a brief outline of the changes. Wordings are mine and not authoritative. An official policy update by the OMC will follow. It was decided by the OMC that starting from now on all committers need to wait for a grace period of (currently) 24 hours after the approval of a pull request has completed (which happens when it has the necessary number of approvals) before they are allowed to merge the pull request to the target branch(es). The two different states are indicated by labels ([approval: done] and [ready to merge]). The 24 hour policy will be endorsed by a server side git hook and a github bot which which controls the [ready to merge] label. There are limited exceptional cases in which a committer can manually set the [ready to merge] label to merge earlier. (e.g. during the release process). Below is a brief overview over the most important new labels. For a full list and for explaining comments, see https://github.com/openssl/openssl/labels Matthias -- *Branch labels* [branch.x.y.z] Branch labels serve as indication of all target branches to which the pull request is going to be merged. Approval of reviewers applies to all target branches, provided the commits can be cherry-picked cleanly. If that's not the case, a separate pull request needs to be made. If there is no branch label, then the github target branch of the pull request is assumed. However, in the future we try to be explicit by allways adding the target branch (e.g., [branch: master]). * Review progress labels* [approval: review pending] [approval: omc review pending] [approval: done] ...24 hour grace period... [ready to merge] * Hold labels* Those labels act as blockers and prevent a pull request from being merged. [hold: cla required] (set by the cla bot, replaces [need-cla], WIP) [hold: license clash] [hold: need omc decision] * Issue type labels* The following labels are going to be set automatically by the issue templates (see pull request https://github.com/openssl/openssl/pull/10266) Templates for the starred labels are still to be done. [issue: bug report] [issue: feature request] [issue: missing documentation] * [issue: question] * From Matthias.St.Pierre at ncp-e.com Sat Oct 26 13:46:56 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 26 Oct 2019 13:46:56 +0000 Subject: Correction: New GitHub labels for pull request and issues - 24 hour grace period Message-ID: <1fab3420bdc84c1b936b6ebfde6f9a0e@Ex13.ncp.local> One small error happened w.r.t. branch labels: they are *Branch labels* [branch: master] [branch: x.y.z] From Matthias.St.Pierre at ncp-e.com Sat Oct 26 14:07:17 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 26 Oct 2019 14:07:17 +0000 Subject: New GitHub labels for pull request and issues - 24 hour grace period Message-ID: <30a4a7da9276478b98b61dc65f92d928@Ex13.ncp.local> Note: names might still undergo some fine tuning. For example, [issue: missing documentation] was just changed to [issue: documentation] to encompass both missing documentation and errors in documentation. Matthias > -----Urspr?ngliche Nachricht----- > Von: openssl-project Im Auftrag von Dr. Matthias St. Pierre > Gesendet: Samstag, 26. Oktober 2019 15:40 > An: openssl-project at openssl.org > Betreff: New GitHub labels for pull request and issues - 24 hour grace period > > Hi all, > > some of you contributors might have already noticed that the labels which > are attached to the GitHub pull requests and issues have changed. > During the face to face meeting it was decided to cleanup some of the > unused labels and to organize the labelling more systematically to match > our review and merging process. > > The following gives you a brief outline of the changes. Wordings are mine > and not authoritative. An official policy update by the OMC will follow. > > It was decided by the OMC that starting from now on all committers need > to wait for a grace period of (currently) 24 hours after the approval of > a pull request has completed (which happens when it has the necessary > number of approvals) before they are allowed to merge the pull request > to the target branch(es). The two different states are indicated by labels > ([approval: done] and [ready to merge]). The 24 hour policy will be endorsed > by a server side git hook and a github bot which which controls the > [ready to merge] label. There are limited exceptional cases in which a > committer can manually set the [ready to merge] label to merge earlier. > (e.g. during the release process). > > Below is a brief overview over the most important new labels. For a full list > and for explaining comments, see > > https://github.com/openssl/openssl/labels > > Matthias > > > -- > > > *Branch labels* > > [branch: master] > [branch: x.y.z] > > Branch labels serve as indication of all target branches to > which the pull request is going to be merged. Approval of > reviewers applies to all target branches, provided the commits > can be cherry-picked cleanly. If that's not the case, a separate > pull request needs to be made. > > If there is no branch label, then the github target branch of the > pull request is assumed. However, in the future we try to be explicit > by allways adding the target branch (e.g., [branch: master]). > > > * Review progress labels* > > [approval: review pending] > [approval: omc review pending] > [approval: done] > > ...24 hour grace period... > [ready to merge] > > > * Hold labels* > > Those labels act as blockers and prevent a pull request from > being merged. > > [hold: cla required] (set by the cla bot, replaces [need-cla], WIP) > [hold: license clash] > [hold: need omc decision] > > > * Issue type labels* > > The following labels are going to be set automatically by the issue templates > (see pull request https://github.com/openssl/openssl/pull/10266) > Templates for the starred labels are still to be done. > > [issue: bug report] > [issue: feature request] > [issue: missing documentation] * > [issue: question] * From matt at openssl.org Tue Oct 29 09:22:35 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 29 Oct 2019 09:22:35 +0000 Subject: Confirmed bug labels Message-ID: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> Do we need a "confirmed bug" or similar label? I was looking at #10283 which is labelled with "issue: bug report". But this only tells us that the reporter thought it was a bug. I wanted to add a label confirming that it really is a bug...but nothing suitable seems to be there. Matt From Matthias.St.Pierre at ncp-e.com Tue Oct 29 11:34:25 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 29 Oct 2019 11:34:25 +0000 Subject: AW: Confirmed bug labels In-Reply-To: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> Message-ID: A similar problem applies to 'issue: feature request'. Just having a 'confirmed' label for bugs wouldn't help in that case. So what do you think about adding a new 'triaged: *' family of labels, in addition to 'issue: *'? 'triaged: bug' 'triaged: feature' etc. If this seems too verbose, then we could just omit the triaged prefix: 'bug' 'feature' etc. Matthias > -----Urspr?ngliche Nachricht----- > Von: openssl-project Im Auftrag von Matt Caswell > Gesendet: Dienstag, 29. Oktober 2019 10:23 > An: openssl-project at openssl.org > Betreff: Confirmed bug labels > > Do we need a "confirmed bug" or similar label? I was looking at #10283 > which is labelled with "issue: bug report". But this only tells us that > the reporter thought it was a bug. I wanted to add a label confirming > that it really is a bug...but nothing suitable seems to be there. > > Matt From matt at openssl.org Tue Oct 29 11:41:17 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 29 Oct 2019 11:41:17 +0000 Subject: AW: Confirmed bug labels In-Reply-To: References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> Message-ID: <9baf25d1-75c2-a8a3-4206-7c53580ef174@openssl.org> On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: > A similar problem applies to 'issue: feature request'. Just having a 'confirmed' label for bugs > wouldn't help in that case. > > So what do you think about adding a new 'triaged: *' family of labels, in addition to 'issue: *'? > > 'triaged: bug' > 'triaged: feature' > etc. > > If this seems too verbose, then we could just omit the triaged prefix: > > 'bug' > 'feature' > etc. Yes, this makes sense to me (and I prefer the more verbose versions). Should we remove the reporter label once its been triaged? It would be quite confusing if you had both the labels "issue: bug report" *and* "triaged: feature" (in the cases where someone reports something as a bug, but we see it as a feature request). Another issue I encountered was with the "closed: *" labels. "closed" doesn't quite seem right to me. Whether something is closed or open is somewhat independent of the states that those labels convey. For example we might want to label something as "not a bug" but leave it open for a little while to allow the reporter to respond or argue why it really should be treated as a bug. Similarly with "wont fix" and maybe even "duplicate". Matt > > Matthias > >> -----Urspr?ngliche Nachricht----- >> Von: openssl-project Im Auftrag von Matt Caswell >> Gesendet: Dienstag, 29. Oktober 2019 10:23 >> An: openssl-project at openssl.org >> Betreff: Confirmed bug labels >> >> Do we need a "confirmed bug" or similar label? I was looking at #10283 >> which is labelled with "issue: bug report". But this only tells us that >> the reporter thought it was a bug. I wanted to add a label confirming >> that it really is a bug...but nothing suitable seems to be there. >> >> Matt From Matthias.St.Pierre at ncp-e.com Tue Oct 29 11:53:35 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 29 Oct 2019 12:53:35 +0100 Subject: AW: Confirmed bug labels In-Reply-To: <9baf25d1-75c2-a8a3-4206-7c53580ef174@openssl.org> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <9baf25d1-75c2-a8a3-4206-7c53580ef174@openssl.org> Message-ID: <681fc595-70b8-e26c-ce1b-b10a23f37a0d@ncp-e.com> On 29.10.19 12:41, Matt Caswell wrote: > > On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: >> A similar problem applies to 'issue: feature request'. Just having a 'confirmed' label for bugs >> wouldn't help in that case. >> >> So what do you think about adding a new 'triaged: *' family of labels, in addition to 'issue: *'? >> >> 'triaged: bug' >> 'triaged: feature' >> etc. >> >> If this seems too verbose, then we could just omit the triaged prefix: >> >> 'bug' >> 'feature' >> etc. > Yes, this makes sense to me (and I prefer the more verbose versions). > Should we remove the reporter label once its been triaged? It would be > quite confusing if you had both the labels "issue: bug report" *and* > "triaged: feature" (in the cases where someone reports something as a > bug, but we see it as a feature request). I agree with you that it should be removed. BTW: That's a similar question than your recent question whether 'approval: done' should be removed when the 'ready to merge' label is added. After sleeping a night over it, I would prefer if the former were removed. If we would add the 'approval: ' prefix, then it would be obvious why it makes sense: ??? 'approval: review pending' ??? 'approval: omc review pending' ??? 'approval: done' ??? ... 24h grace period ... ??? 'approval: ready to merge' The transition diagram would be much easier to remember, in particular for the case when an approval needs to be revoked because some change was added (or even force-pushed) after approval. > Another issue I encountered was with the "closed: *" labels. "closed" > doesn't quite seem right to me. Whether something is closed or open is > somewhat independent of the states that those labels convey. For example > we might want to label something as "not a bug" but leave it open for a > little while to allow the reporter to respond or argue why it really > should be treated as a bug. Similarly with "wont fix" and maybe even > "duplicate". Actually the 'rejected: *' prefix would be the most appropriate. I just hesitated because it sounded so unfriendly. If you have a more friendly proposal, I'd be happy to hear about it. Otherwise I would just suggest to use it instead of 'closed: *'. Matthias From matt at openssl.org Tue Oct 29 11:57:03 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 29 Oct 2019 11:57:03 +0000 Subject: AW: Confirmed bug labels In-Reply-To: <681fc595-70b8-e26c-ce1b-b10a23f37a0d@ncp-e.com> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <9baf25d1-75c2-a8a3-4206-7c53580ef174@openssl.org> <681fc595-70b8-e26c-ce1b-b10a23f37a0d@ncp-e.com> Message-ID: <6ef2a4a2-45c9-4f6b-b7d3-a876efdacae7@openssl.org> On 29/10/2019 11:53, Matthias St. Pierre wrote: > > > On 29.10.19 12:41, Matt Caswell wrote: >> >> On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: >>> A similar problem applies to 'issue: feature request'.? Just having a >>> 'confirmed' label for bugs >>> wouldn't help in that case. >>> >>> So what do you think about adding a new 'triaged: *' family of >>> labels, in addition to 'issue: *'? >>> >>> ????'triaged: bug' >>> ????'triaged: feature' >>> ????etc. >>> >>> If this seems too verbose, then we could just omit the triaged prefix: >>> >>> ????'bug' >>> ????'feature' >>> ????etc. >> Yes, this makes sense to me (and I prefer the more verbose versions). >> Should we remove the reporter label once its been triaged? It would be >> quite confusing if you had both the labels "issue: bug report" *and* >> "triaged: feature" (in the cases where someone reports something as a >> bug, but we see it as a feature request). > > I agree with you that it should be removed. > > > BTW: That's a similar question than your recent question whether > 'approval: done' should be removed when the 'ready to merge' > label is added. After sleeping a night over it, I would prefer if > the former were removed. If we would add the 'approval: ' prefix, > then it would be obvious why it makes sense: > > ??? 'approval: review pending' > ??? 'approval: omc review pending' > ??? 'approval: done' > > ??? ... 24h grace period ... > > ??? 'approval: ready to merge' > > The transition diagram would be much easier to remember, in particular > for the case when an approval needs to be revoked because some change > was added (or even force-pushed) after approval. Yes - ok. That's a good argument. > > > >> Another issue I encountered was with the "closed: *" labels. "closed" >> doesn't quite seem right to me. Whether something is closed or open is >> somewhat independent of the states that those labels convey. For example >> we might want to label something as "not a bug" but leave it open for a >> little while to allow the reporter to respond or argue why it really >> should be treated as a bug. Similarly with "wont fix" and maybe even >> "duplicate". > > Actually the 'rejected: *' prefix would be the most appropriate. I just > hesitated > because it sounded so unfriendly. If you have a more friendly proposal, > I'd be > happy to hear about it. Otherwise I would just suggest to use it instead of > 'closed: *'. "rejected" isn't even quite right either. E.g. in the case of "wont fix" its not that we are disputing that what they've told us isn't true - just that we're not going to do anything about it. How about "resolved: *" instead? Matt From Matthias.St.Pierre at ncp-e.com Tue Oct 29 11:57:23 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 29 Oct 2019 12:57:23 +0100 Subject: AW: Confirmed bug labels In-Reply-To: <681fc595-70b8-e26c-ce1b-b10a23f37a0d@ncp-e.com> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <9baf25d1-75c2-a8a3-4206-7c53580ef174@openssl.org> <681fc595-70b8-e26c-ce1b-b10a23f37a0d@ncp-e.com> Message-ID: <7bcd0b11-9353-983e-2ac7-08a5831b30a3@ncp-e.com> Another idea just occurred to me: we could join the 'closed: *' labels with the 'triaged: *' labels: ??? triaged: duplicate ??? triaged: not a bug ??? triaged: wont fix On 29.10.19 12:53, Matthias St. Pierre wrote: > > > On 29.10.19 12:41, Matt Caswell wrote: >> >> On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: >>> A similar problem applies to 'issue: feature request'.? Just having a 'confirmed' label for bugs >>> wouldn't help in that case. >>> >>> So what do you think about adding a new 'triaged: *' family of labels, in addition to 'issue: *'? >>> >>> ????'triaged: bug' >>> ????'triaged: feature' >>> ????etc. >>> >>> If this seems too verbose, then we could just omit the triaged prefix: >>> >>> ????'bug' >>> ????'feature' >>> ????etc. >> Yes, this makes sense to me (and I prefer the more verbose versions). >> Should we remove the reporter label once its been triaged? It would be >> quite confusing if you had both the labels "issue: bug report" *and* >> "triaged: feature" (in the cases where someone reports something as a >> bug, but we see it as a feature request). > > I agree with you that it should be removed. > > > BTW: That's a similar question than your recent question whether > 'approval: done' should be removed when the 'ready to merge' > label is added. After sleeping a night over it, I would prefer if > the former were removed. If we would add the 'approval: ' prefix, > then it would be obvious why it makes sense: > > ??? 'approval: review pending' > ??? 'approval: omc review pending' > ??? 'approval: done' > > ??? ... 24h grace period ... > > ??? 'approval: ready to merge' > > The transition diagram would be much easier to remember, in particular > for the case when an approval needs to be revoked because some change > was added (or even force-pushed) after approval. > > > >> Another issue I encountered was with the "closed: *" labels. "closed" >> doesn't quite seem right to me. Whether something is closed or open is >> somewhat independent of the states that those labels convey. For example >> we might want to label something as "not a bug" but leave it open for a >> little while to allow the reporter to respond or argue why it really >> should be treated as a bug. Similarly with "wont fix" and maybe even >> "duplicate". > > Actually the 'rejected: *' prefix would be the most appropriate. I just hesitated > because it sounded so unfriendly. If you have a more friendly proposal, I'd be > happy to hear about it. Otherwise I would just suggest to use it instead of > 'closed: *'. > > > Matthias > From Matthias.St.Pierre at ncp-e.com Tue Oct 29 11:59:06 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 29 Oct 2019 12:59:06 +0100 Subject: AW: Confirmed bug labels In-Reply-To: <7bcd0b11-9353-983e-2ac7-08a5831b30a3@ncp-e.com> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <9baf25d1-75c2-a8a3-4206-7c53580ef174@openssl.org> <681fc595-70b8-e26c-ce1b-b10a23f37a0d@ncp-e.com> <7bcd0b11-9353-983e-2ac7-08a5831b30a3@ncp-e.com> Message-ID: Our replies overlapped. 'resolved: *' is even better than 'triaged: *'. On 29.10.19 12:57, Matthias St. Pierre wrote: > Another idea just occurred to me: we could join the 'closed: *' labels with the 'triaged: *' labels: > > ??? triaged: duplicate > ??? triaged: not a bug > ??? triaged: wont fix From Matthias.St.Pierre at ncp-e.com Tue Oct 29 12:09:05 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 29 Oct 2019 13:09:05 +0100 Subject: Confirmed bug labels In-Reply-To: <67735F74-C95F-4F50-AF55-EFDED4EA1C1F@akamai.com> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <67735F74-C95F-4F50-AF55-EFDED4EA1C1F@akamai.com> Message-ID: <55340ae7-c251-ac61-a719-cb765cb2ca65@ncp-e.com> We try to group the labels into categories using prefixes, see https://github.com/openssl/openssl/labels and my initial post https://mta.openssl.org/pipermail/openssl-project/2019-October/001593.html Note that the 'issue: *' labels are automatically added by the GitHub issue templates, because normal users don't have the permissions to add those labels. Alternative proposals are welcome, but they need to fit into the new naming scheme. Matthias On 29.10.19 13:04, Salz, Rich wrote: > What about "proposed bug" "proposed feature" etc. And a single "accepted" label? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 29 12:14:32 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 29 Oct 2019 12:14:32 +0000 Subject: AW: Confirmed bug labels In-Reply-To: References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> Message-ID: <98db5a22-e450-813a-da5c-d71c4bc61219@openssl.org> On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: > A similar problem applies to 'issue: feature request'. Just having a 'confirmed' label for bugs > wouldn't help in that case. > > So what do you think about adding a new 'triaged: *' family of labels, in addition to 'issue: *'? > > 'triaged: bug' > 'triaged: feature' > etc. Do we just need "triaged: bug" and "triaged: feature"? Or should we also have "triaged: documentation" and "triaged: question" (so that there is one for every corresponding "issue" label)? Bugs, features and documentation issues are resolved by fixing/implementing them, or marking them with a resolved label. Should we also have a "resolved: answered" label where we believe we have answered a question? Possibly also one where there has been no answer, but we're closing it because the question is stale? I updated the "closed: *" labels to say "resolved: *" instead. Matt > > If this seems too verbose, then we could just omit the triaged prefix: > > 'bug' > 'feature' > etc. > > Matthias > >> -----Urspr?ngliche Nachricht----- >> Von: openssl-project Im Auftrag von Matt Caswell >> Gesendet: Dienstag, 29. Oktober 2019 10:23 >> An: openssl-project at openssl.org >> Betreff: Confirmed bug labels >> >> Do we need a "confirmed bug" or similar label? I was looking at #10283 >> which is labelled with "issue: bug report". But this only tells us that >> the reporter thought it was a bug. I wanted to add a label confirming >> that it really is a bug...but nothing suitable seems to be there. >> >> Matt From rsalz at akamai.com Tue Oct 29 12:04:24 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 29 Oct 2019 12:04:24 +0000 Subject: Confirmed bug labels In-Reply-To: References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> Message-ID: <67735F74-C95F-4F50-AF55-EFDED4EA1C1F@akamai.com> What about "proposed bug" "proposed feature" etc. And a single "accepted" label? From Matthias.St.Pierre at ncp-e.com Tue Oct 29 12:24:55 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 29 Oct 2019 13:24:55 +0100 Subject: AW: Confirmed bug labels In-Reply-To: <98db5a22-e450-813a-da5c-d71c4bc61219@openssl.org> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <98db5a22-e450-813a-da5c-d71c4bc61219@openssl.org> Message-ID: <9e2f1817-25d4-ca5a-da7a-899184bf8833@ncp-e.com> On 29.10.19 13:14, Matt Caswell wrote: > Do we just need "triaged: bug" and "triaged: feature"? Or should we also > have "triaged: documentation" and "triaged: question" (so that there is > one for every corresponding "issue" label)? Yes, that makes sense. Then it is assured that the 'issue: *' labels are set only for issues which have not been triaged yet. Note also that the 'triaged: bug', 'triaged: feature', and 'triaged: documentation' labels also make sense for pull request, in particular w.r.t. the question whether a pull request can be backported or not. > > Bugs, features and documentation issues are resolved by > fixing/implementing them, or marking them with a resolved label. Should > we also have a "resolved: answered" label where we believe we have > answered a question? Possibly also one where there has been no answer, > but we're closing it because the question is stale? It might be useful to add more reasons for why the issue is resolved. OTOH we should watch out that we don't create too many labels. ??? "resolved: fixed" ??? "resolved: answered" ??? ... For the unresolved issues, an 'unresolved: *' label makes sense: ??? "unresolved: " > > I updated the "closed: *" labels to say "resolved: *" instead. Ok, I already saw it :-) From matt at openssl.org Tue Oct 29 12:34:40 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 29 Oct 2019 12:34:40 +0000 Subject: AW: Confirmed bug labels In-Reply-To: <9e2f1817-25d4-ca5a-da7a-899184bf8833@ncp-e.com> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <98db5a22-e450-813a-da5c-d71c4bc61219@openssl.org> <9e2f1817-25d4-ca5a-da7a-899184bf8833@ncp-e.com> Message-ID: <4e6fa00c-210d-094e-a352-4d2ba98c1ae4@openssl.org> On 29/10/2019 12:24, Matthias St. Pierre wrote: > > > On 29.10.19 13:14, Matt Caswell wrote: >> Do we just need "triaged: bug" and "triaged: feature"? Or should we also >> have "triaged: documentation" and "triaged: question" (so that there is >> one for every corresponding "issue" label)? > > Yes, that makes sense. Then it is assured that the 'issue: *' labels are > set only for issues which have not been triaged yet. > > Note also that the 'triaged: bug', 'triaged: feature', and 'triaged: > documentation' > labels also make sense for pull request, in particular w.r.t. the > question whether > a pull request can be backported or not. > >> >> Bugs, features and documentation issues are resolved by >> fixing/implementing them, or marking them with a resolved label. Should >> we also have a "resolved: answered" label where we believe we have >> answered a question? Possibly also one where there has been no answer, >> but we're closing it because the question is stale? > > It might be useful to add more reasons for why the issue is resolved. > OTOH we should watch out that we don't create too many labels. > > ??? "resolved: fixed" > ??? "resolved: answered" Not sure about the "resolved: fixed" one...most of the time where we resolve an issue by fixing it, it gets closed automatically. Adding a label probably doesn't add much. I suppose it might be useful in the case where someone reports a bug that is *already* fixed in a later version. > ??? ... > > For the unresolved issues, an 'unresolved: *' label makes sense: > > ??? "unresolved: " Possible reasons for marking something as unresolved: - The question is stale - no activity for a prolonged period - Off topic - the question is about something not directly related to OpenSSL - Unable to help - despite our best efforts we weren't able to figure out an answer - Lack of information - we requested information and it wasn't forthcoming Not sure if we would want a label for all of those or not. Matt From Matthias.St.Pierre at ncp-e.com Tue Oct 29 12:37:12 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 29 Oct 2019 13:37:12 +0100 Subject: AW: Confirmed bug labels In-Reply-To: <9e2f1817-25d4-ca5a-da7a-899184bf8833@ncp-e.com> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <98db5a22-e450-813a-da5c-d71c4bc61219@openssl.org> <9e2f1817-25d4-ca5a-da7a-899184bf8833@ncp-e.com> Message-ID: <879375e3-1894-f027-f13f-f7f9010e4b26@ncp-e.com> The 'unresolved: *' labels could carry the same grey color as the 'resolved: *' labels. For the 'triaged: *' labels we need a new color. I can make a suggestion... Matthias From matt at openssl.org Tue Oct 29 12:38:03 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 29 Oct 2019 12:38:03 +0000 Subject: AW: Confirmed bug labels In-Reply-To: <879375e3-1894-f027-f13f-f7f9010e4b26@ncp-e.com> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <98db5a22-e450-813a-da5c-d71c4bc61219@openssl.org> <9e2f1817-25d4-ca5a-da7a-899184bf8833@ncp-e.com> <879375e3-1894-f027-f13f-f7f9010e4b26@ncp-e.com> Message-ID: On 29/10/2019 12:37, Matthias St. Pierre wrote: > The 'unresolved: *' labels could carry the same grey color as the > 'resolved: *' labels. > For the 'triaged: *' labels we need a new color. I can make a suggestion... Please do! Matt From Matthias.St.Pierre at ncp-e.com Tue Oct 29 12:42:12 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 29 Oct 2019 13:42:12 +0100 Subject: AW: Confirmed bug labels In-Reply-To: <4e6fa00c-210d-094e-a352-4d2ba98c1ae4@openssl.org> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <98db5a22-e450-813a-da5c-d71c4bc61219@openssl.org> <9e2f1817-25d4-ca5a-da7a-899184bf8833@ncp-e.com> <4e6fa00c-210d-094e-a352-4d2ba98c1ae4@openssl.org> Message-ID: On 29.10.19 13:34, Matt Caswell wrote: > >> ??? ... >> >> For the unresolved issues, an 'unresolved: *' label makes sense: >> >> ??? "unresolved: " > Possible reasons for marking something as unresolved: > > - The question is stale - no activity for a prolonged period > - Off topic - the question is about something not directly related to > OpenSSL > - Unable to help - despite our best efforts we weren't able to figure > out an answer > - Lack of information - we requested information and it wasn't forthcoming > > Not sure if we would want a label for all of those or not. > > Matt > Then I'll just add a simple 'unresolved' label without a reason and we can extend labels if needed. From Matthias.St.Pierre at ncp-e.com Tue Oct 29 13:07:46 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 29 Oct 2019 14:07:46 +0100 Subject: AW: Confirmed bug labels In-Reply-To: References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <98db5a22-e450-813a-da5c-d71c4bc61219@openssl.org> <9e2f1817-25d4-ca5a-da7a-899184bf8833@ncp-e.com> <879375e3-1894-f027-f13f-f7f9010e4b26@ncp-e.com> Message-ID: <1b9a0a01-f31b-7853-df87-5ff8a266bb3f@ncp-e.com> I decided to change the 'issue: *' colors to a more 'yelling' cyan color making the untriaged issues more prominent, and use the more relaxed blue color for the 'triaged: *' labels instead. Also added an 'unresolved' label. Matthias On 29.10.19 13:38, Matt Caswell wrote: > > On 29/10/2019 12:37, Matthias St. Pierre wrote: >> The 'unresolved: *' labels could carry the same grey color as the >> 'resolved: *' labels. >> For the 'triaged: *' labels we need a new color. I can make a suggestion... > Please do! > > Matt From Matthias.St.Pierre at ncp-e.com Tue Oct 29 13:15:42 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 29 Oct 2019 14:15:42 +0100 Subject: GitHub Milestones Message-ID: Since the reorganization of the labels is mostly complete (except for automation), the next step could now be to clean up the old milestones. But that's more a task for Matt and Richard. https://github.com/openssl/openssl/milestones Matthias From Matthias.St.Pierre at ncp-e.com Tue Oct 29 13:51:30 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 29 Oct 2019 14:51:30 +0100 Subject: Triage of issues using the new labels Message-ID: <5ab356a3-8a53-ddc6-ddd7-a434c8155201@ncp-e.com> Hi, after some discussion with Matt, some new 'triaged:*' GitHub labels have been added in addition to the 'issue: *' labels. The idea is that the 'issue: *' labels are going to be added by the reporter by choosing the corresponding GitHub issue template (there will be one template for every issue type when #10051 is merged). When we committers first look at the issue, we can decide of what type the issue and add an appropriate 'triaged: *' label. This type can be different from what the reporter chose, if we disagree with his opinion. When we add the 'triaged: *' label, the 'issue: *' label should be removed (IMHO). In this way, we can distinguish between untriaged and triaged tickets. It would be great, if you all could look through the labelled issues in the next days/weeks and help with the triage. Ideally, only new untriaged tickets should carry one of the 'issue: *' labels. ??? issue: bug report https://github.com/openssl/openssl/labels/issue%3A%20bug%20report ??? issue: documentation https://github.com/openssl/openssl/labels/issue%3A%20documentation ??? issue: feature request https://github.com/openssl/openssl/labels/issue%3A%20feature%20request ??? issue: question https://github.com/openssl/openssl/labels/issue%3A%20question Regards, Matthias From Matthias.St.Pierre at ncp-e.com Wed Oct 30 08:26:42 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 30 Oct 2019 08:26:42 +0000 Subject: Re-requesting reviews on GitHub Message-ID: Independently of the new 'approval: *' state labelling I was wondering whether it wouldn't be a good idea to adopt the habit of explicitly requesting a re-review from the other reviewers after significant changes, using the mechanism provided by GitHub (i.e. the button with the two circling arrows next to the reviewer entry). In that way, outdated reviews would become more visible, and outdated reviews wouldn't be addrev'ed to the commit message when merging, unless they are renewed before the 24h grace period expires. For nit changes, the current informal way of re-approval could be kept of course. What's your opinion? Matthias From Matthias.St.Pierre at ncp-e.com Wed Oct 30 08:30:11 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 30 Oct 2019 08:30:11 +0000 Subject: AW: Re-requesting reviews on GitHub In-Reply-To: References: Message-ID: <16b2b3e634bb45a2b4d525c4d7fdb521@Ex13.ncp.local> > Independently of the new 'approval: *' state labelling I was wondering whether it wouldn't > be a good idea to adopt the habit of explicitly requesting a re-review from the other reviewers > after significant changes, using the mechanism provided by GitHub (i.e. the button with the two To be more precise: not all reviews need to be invalidated by requesting a re-review, only the approvals. From levitte at openssl.org Wed Oct 30 09:14:28 2019 From: levitte at openssl.org (Richard Levitte) Date: Wed, 30 Oct 2019 10:14:28 +0100 Subject: Re-requesting reviews on GitHub In-Reply-To: <16b2b3e634bb45a2b4d525c4d7fdb521@Ex13.ncp.local> References: <16b2b3e634bb45a2b4d525c4d7fdb521@Ex13.ncp.local> Message-ID: <9382C199-6BEB-4C8F-8AAC-F80E4EFDBF05@openssl.org> This is a good idea, and also a detectable event for a bot to listen to. Cheers Richard "Dr. Matthias St. Pierre" skrev: (30 oktober 2019 09:30:11 CET) >> Independently of the new 'approval: *' state labelling I was >wondering whether it wouldn't >> be a good idea to adopt the habit of explicitly requesting a >re-review from the other reviewers >> after significant changes, using the mechanism provided by GitHub >(i.e. the button with the two > >To be more precise: not all reviews need to be invalidated by >requesting a re-review, only the approvals. -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From matt at openssl.org Wed Oct 30 10:42:26 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 30 Oct 2019 10:42:26 +0000 Subject: AW: Confirmed bug labels In-Reply-To: <4e6fa00c-210d-094e-a352-4d2ba98c1ae4@openssl.org> References: <331490c2-6959-efb6-cd55-d4bb3da549f8@openssl.org> <98db5a22-e450-813a-da5c-d71c4bc61219@openssl.org> <9e2f1817-25d4-ca5a-da7a-899184bf8833@ncp-e.com> <4e6fa00c-210d-094e-a352-4d2ba98c1ae4@openssl.org> Message-ID: <954d9797-7680-02ad-2ec7-f9ffa1140871@openssl.org> On 29/10/2019 12:34, Matt Caswell wrote: > > > On 29/10/2019 12:24, Matthias St. Pierre wrote: >> >> It might be useful to add more reasons for why the issue is resolved. >> OTOH we should watch out that we don't create too many labels. >> >> ??? "resolved: fixed" >> ??? "resolved: answered" > > Not sure about the "resolved: fixed" one...most of the time where we > resolve an issue by fixing it, it gets closed automatically. Adding a > label probably doesn't add much. I suppose it might be useful in the > case where someone reports a bug that is *already* fixed in a later version. I found myself needing to use "resolved: answered" so I added it. Matt From psteuer9 at gmail.com Wed Oct 30 11:17:44 2019 From: psteuer9 at gmail.com (Patrick Steuer) Date: Wed, 30 Oct 2019 12:17:44 +0100 Subject: Re-requesting reviews on GitHub In-Reply-To: References: Message-ID: <63d59f63-75f2-017a-661e-0b30db63e0f0@gmail.com> I think its a good idea. It would prevent issues like https://github.com/openssl/openssl/pull/9501 Patrick From Matthias.St.Pierre at ncp-e.com Wed Oct 30 13:25:19 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Wed, 30 Oct 2019 14:25:19 +0100 Subject: Re-requesting reviews on GitHub In-Reply-To: <9382C199-6BEB-4C8F-8AAC-F80E4EFDBF05@openssl.org> References: <16b2b3e634bb45a2b4d525c4d7fdb521@Ex13.ncp.local> <9382C199-6BEB-4C8F-8AAC-F80E4EFDBF05@openssl.org> Message-ID: <54965722-67cc-b074-cc67-0ab8c0feaa28@ncp-e.com> On 30.10.19 10:14, Richard Levitte wrote: > This is a good idea, and also a detectable event for a bot to listen to. Sounds like an excellent idea: If approvals and dismissals of approvals (resp. re-review requests) are all bot events, then the bot should be able to handle most state changes automatically, including the determination whether a normal or an omc review is required.? This would be a great ease for the reviewer's workflow. Matthias