On 2017-03-14 13:46, Michael Dürig wrote:
...
The code review is something we should be doing anyway. The only added
overhead here is the extra email asking for review. This is a bit of
extra work for the person doing the backport but saves a couple of
others time figuring out what a commit is about, its criticality, risk
etc. Overall the effort would actually be less. And this doesn't even
take into account all the extra effort a rogue backport would cause
should we miss it by the standard CTR policy.
...
Well, we have:
1) labels for backport candidates,
2) commit emails,
3) release notes and voting for releases.
I'd argue that all these existing steps already provide opportunity for
collecting review.
Let me suggest something else:
a) follow commit emails,
b) when we do a release from a stable branch, actually review what
changed, instead of just ~3 people only running the release checker script.
I'd also propose that when we announce the release plan, we include the
candidate release notes, so it's less work to see what changes would be
included.
Best regards, Julian
