Open Stack

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.
>
>