It seems we have the same thoughts... Regards,
Paul Yang > On Dec 12, 2019, at 5:36 PM, Dr Paul Dale <paul.d...@oracle.com> wrote: > > I agree that there is a possible flaw in the workflow. What’s saved us so > far is that new contributors don’t generally include the "CLA: trivial" line > or put it in the GitHub text. > > Could we have a “trivial” tag that is added whenever the "CLA: trivial" line > is present? Better would be to add it only if the submitter doesn’t have a > CLA on file but either works. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 12 Dec 2019, at 7:20 pm, Matt Caswell <m...@openssl.org >> <mailto:m...@openssl.org>> wrote: >> >> I notice that PR 10594 (Add support for otherName:NAIRealm in output) >> got merged yesterday: >> https://github.com/openssl/openssl/pull/10594 >> <https://github.com/openssl/openssl/pull/10594> >> >> The commit description contained "CLA: trivial" and so the "hold: cla >> required" label was not automatically applied to the PR. But the >> discussion in the PR suggested a CLA should be submitted. But it got >> merged anyway! Fortunately the CLA had already been processed - just not >> noted in the PR. So, in this case, it makes no difference. >> >> I think this points to a possible flaw in our workflow for dealing with >> trivial changes. Because the "CLA: trivial" header suppresses the "hold: >> cla required" label and the git hooks don't complain when commits get >> pushed with the "CLA: trivial" header and no CLA on file, it seems >> possible to me that we could push commit all the way through the process >> without the reviewers even realising that the author is claiming >> triviality on the commit. >> >> Not sure what the solution to that is. >> >> Matt >
signature.asc
Description: Message signed with OpenPGP
