AW: [openssl] OpenSSL_1_1_1-stable update

[Matt Caswell]

On 24/05/2019 15:10, Richard Levitte wrote:
> Not sure I see it as picking nits, it's rather about some fundamental
> difference in what we thinking we're approving, and how we actually
> act around that.
> 
> My idea has always been that I approve a code change, i.e. essentially
> a patch or a set of patches, without regard for exact branches it ends
> up in.  With the in mind, the exact branches it gets applied to is a
> *separate* question.

That's not the way I've ever thought of it. In my mind an approval is for a
change applied to a specific branch. Where a PR lists more than one branch in it
and you approve the PR then effectively you are approving it multiple times all
in one go - once for each branch.


> If we go with the idea that an approval also involves approving what
> branches it goes to, then what happens if someone realises after some
> time that a set of commits (a PR) that was applied to master only
> should really also be applied to 1.1.1?  Should the approval process
> start over from scratch, i.e. all approvals that went to master should
> be scratched and replaced with a new set of approvals (in principle)?

No. If the PR was approved for master and applied to master then no problem - it
stays in master. If it is later realised that it needs to be backported to other
branches then, yes, new approvals need to be sought for that change to *those
branches*.

As far as I was aware we've always done this.

This is essential in my mind. A change for one branch does not always make sense
in another branch. So you can't just say "I approve this change" and *then*
worry about what branches it applies to. A change only makes sense in the
context of the branch it applies to.

Matt