<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif">I think we changed enough things in the test infrastructure that there is a chance of creating subtle failures by merging cherry-picked commits from master directly.<br><br>From the burden perspective, from my point of view having a separate PR that ran all the CI without failures is actually a benefit: I can do some minimal testing on my machine before the final merge, instead of having to push a branch to my personal github fork to run travis and appveyor to test weird build options on platforms I don't have access to.<br><br>If we stick to opening the PR for backporting only after master is completely approved, there shouldn't be too big a burden for the original reviewers either: we can use `fixup!` commits if trivial changes are required to clearly highlight what was changed compared to the original PR for master, and other than that it's just a matter of checking that nothing else changed from the originally approved changes. Approvals conditional to the CI passing can also help to further reduce the burden of the grace period for backport PRs.<br><br><br>Nicola</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 29 Apr 2020 at 14:24, Dr Paul Dale <<a href="mailto:paul.dale@oracle.com">paul.dale@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">My concern is are 1.1.1 and 3.0 really all that different?<div>The core is quite different but the cryptographic algorithms aren’t.  CMS, x509, …?</div><div><br></div><div>I’d rather not introduce a burden where it isn’t necessary.</div><div><br></div><div>Pauli</div><div>
<div dir="auto" style="overflow-wrap: break-word;"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">-- <br>Dr Paul Dale | Distinguished Architect | Cryptographic Foundations <br>Phone +61 7 3031 7217<br>Oracle Australia</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><br></div><br>
</div>

<div><br><blockquote type="cite"><div>On 29 Apr 2020, at 10:08 pm, Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>> wrote:</div><br><div><div><br>The OTC have received this proposal and a request that we vote on it:<br><br>I would like to request that we do not allow cherry-picks between master<br>and 1.1.1-stable because these two versions are now very different, if a<br>cherry-pick succeeds, there is no guarantee that the result will work.<br>Because we have no CI for the cherry-pick. If a cherry-pick is needed, a<br>new PR for 1.1.1 should be done and approved independently.<br><br>Before starting a vote I'd like to provide opportunity for comments, and<br>also what the vote text should be.<br><br>Thanks<br><br>Matt<br></div></div></blockquote></div><br></div></blockquote></div>