openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

Hi Nati

(Restarting our offline discussion here ...)

I see you've proposed a stack of changes to Nova. Nice work! Kudos!

  https://review.openstack.org/#q,status:open+project:openstack/nova+branch:stable/diablo+owner:nati,n,z

However, they shouldn't be submitted against the stable/diablo branch.
If they were just merged there, they would never make it into the Essex
and later releases.

The policy for what is acceptable in the stable branch is documented
here:

  http://wiki.openstack.org/StableBranch

The policy is pretty standard practice for stable branches and the
reasons for it include:

  1) We try and reduce the risk of regressions on the stable branch to 
     the absolute minimum. We also try to reduce the size and number of
     changes so that people using the stable branch can be confident 
     that the risk of the changes is low and they can review the 
     changes themselves.

  2) Getting fixes onto the main development branch before applying 
     them to the stable branch means we have a good chance of catching 
     any regressions caused by the fix on master before it has a chance 
     to cause a regression on the stable branch.

  3) But most importantly, the policy is there to ensure that people 
     don't focus on stable branches to the detriment of the development 
     branch. If everyone focused their effort on fixing the stable 
     branch and never included those fixes in the development branch, 
     every new release would be in terrible shape and the fixing effort 
     would have to start over again.

I think you're in the situation that (3) is trying to prevent.

i.e. you and your team are focused on testing and fixing Diablo and
don't have the time to submit your fixes against Essex. While it's great
to see your fixes, IMHO you really need to think longer term.

If you leave it until later to rebase the fixes onto master, you'll
probably find it to be very difficult and may never complete the rebase.
And if you never complete the rebase, all your effort is essentially
wasted in the long term.

I think most of the Linux distributors learnt this lesson the hard way
over the years and now have an "upstream first" policy. Hopefully we can
save you the pain of dealing a similar mess when Essex comes out! :-)

Thanks,
Mark.