Open Stack

Hi Nati,

I think it's fair to say there is very strong consensus around the
policy that only changes that have been accepted into master should be
considered for the stable branch.

It's not unusual for people to focus their QA efforts on a stable
branch. However, it is crucial that any fixes for bugs discovered during
this QA process are first applied to the master branch.

Your situation is slightly unusual in that a large part of your QA
effort seems to be writing new unit tests against the stable branch.
Perhaps this is a reasonable way of finding issues whose fixes would be
suitable for stable branch, but I think these tests would have much more
value if they were added to the master branch. I'd be hesitant to accept
backports of a large number of new test cases to stable branch.

In any case, I really hope you can figure out how to adjust your
workflow such that fixes and new test cases flow into the master branch.
We really want all your cool work upstream! :-)

In the meantime, I'm going to -2 all the reviews submitted against the
stable branch because too many people are being confused into thinking
that these are patches for master.

Thanks,
Mark.

On Tue, 2011-11-08 at 10:19 -0800, Nachi Ueno wrote:
> Hi Mark
> 
> Thank you for your sharing discussion.
> # hmm, If I could create new instance of me, problem will be fixed.
> 
> I understand your point. Stop QAing stable/diablo and focus on Essex.
> Ideally, we should focus on upstream branch. Ideally, we can start use
> the code after release out.
> 
> However the current situation is different. IMO the quality diablo is
> not ready for real deployment.
> In the diablo summit, I think we agreed the policy "Do not decrease
> code coverage on merge".
> But it is not applied through diablo timeframe,and the diablo has
> small coverage.
> 
> And for essex, the specs are changing, so it is quite difficult QA by
> non-implementer.
> In addition, to wait 6 month is not allowed for my team.
> So QAing stable/branch with fixed specs is very important.
> 
> Our contribution is 1000 unit test cases for stable/diablo nova, and bug patch
> (I'm not sure all test could be used for Essex) #Sorry i sent wrong
> number for you.
> There test cases found about 60 bugs. And also we are writing each bag patch.
> https://bugs.launchpad.net/nova/+bugs?search=Search&field.bug_reporter=nati-ueno
> 
> For test case, it didn't have bad effect for code. Otherwise they
> helps keep quality of code. No violation for (1).
> So I think it should be merged to stable/diablo.
> 
> For bug patch, it should be discussed case-by-case.
> Some large refactoring have done already for Essex,then some bugs are
> fixed on the refactoring.
> 
> We are struggling with very tight schedule. X(
> If our contribution is rejected to the stable/diablo, to maintain our
> own branch is only option for us.
> And I don't really want to do this.
> 
> 
> 2011/11/8 Mark McLoughlin <markmc at redhat.com>:
> > 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.
> >
> >
> 
> 
>