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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/