Open Stack

Hi Fuelers,

I would like to address a concern I have with backporting policy. I'm sure
all of you know that we should always land patches to master before it
reaches stable/X.X branch. What you are not aware of probably is that many
people are making cherry picks well in advance of gathering reviews and
getting the patch landed in master. Some argue that it "saves time waiting
on CI", but in reality it's quite the opposite. Adding a cherry pick before
merging master causes the following workflow to take place:
1 - Propose to master and to stable/7.0
2 - CI runs on 2 patches
3 - Reviewer A comments on master patch
4 - owner adjusts both patches and runs CI
5 - Reviewer B comments on stable patch
6 - owner adjusts both patches and runs CI
(repeat 3-6 in varying degrees until enough patches are gathered)
7 - rebase stable/7.0 patch again... wait for CI again

This doubles the burden on CI and complicates the overall review process
where we are accepting feedback for the initial solution on two (nearly)
identical patches. What's worse is it's possible that the two solutions
merged won't be identical and introduce potential regressions.

I propose we avoid raising any stable/X.X patches before a patch is
_merged_ into master to avoid this scenario. Additionally, if a core sees
that this is happening, he or she should mark it -2 and discourage
submission of new patchsets.

I welcome your thoughts and feedback.

Best Regards,
Matthew Mosesohn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151002/14112a2f/attachment.html>