AW: [openssl] OpenSSL_1_1_1-stable update

[Richard Levitte]

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.

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)?
So far, we have never acted that way.

On Fri, 24 May 2019 15:24:48 +0200,
Dr. Matthias St. Pierre wrote:
> 
> Matt and Richard, I think you are mixing up cherry-picking and nit-picking here. (Sorry for the pun ;-)
> 
> Matthias
> 
> > To be picky, may I assume that you meant a reviewed-by tag for you
> > > should be *added*?  The commit itself (its contents) having been
> > > reviewed by those already there, I cannot see a reason why they should
> > > be removed.
> > 
> > You approved for master but did not approve for 1.1.1. This commit was merged to
> > 1.1.1 and so strictly speaking was not approved by you for that branch.
> > Therefore you should have been removed, and I should have been added.
> > 
> > Matt
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/