<div dir="ltr"><div dir="ltr">Hello,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 24, 2019 at 5:21 PM Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</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"><br>
On 24/05/2019 15:10, Richard Levitte wrote:<br>> If we go with the idea that an approval also involves approving what<br>
> branches it goes to, then what happens if someone realises after some<br>
> time that a set of commits (a PR) that was applied to master only<br>
> should really also be applied to 1.1.1?  Should the approval process<br>
> start over from scratch, i.e. all approvals that went to master should<br>
> be scratched and replaced with a new set of approvals (in principle)?<br>
<br>
No. If the PR was approved for master and applied to master then no problem - it<br>
stays in master. If it is later realised that it needs to be backported to other<br>
branches then, yes, new approvals need to be sought for that change to *those<br>
branches*.<br>
<br>
As far as I was aware we've always done this.<br>
<br>
This is essential in my mind. A change for one branch does not always make sense<br>
in another branch. So you can't just say "I approve this change" and *then*<br>
worry about what branches it applies to. A change only makes sense in the<br>
context of the branch it applies to.<br>
<br></blockquote><div><br></div><div>I agree with Matt. For example, a patch providing new functionality cat be cleanly applicable </div><div>to master and stable branches, but if it is applied to a stable branch, it breaks the policy.</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>