Open Stack

> On 14.10.2013, at 11:18, "Thierry Carrez" <thierry at openstack.org> wrote:
> 
> Joe Gordon wrote:
>> [...]
>> This sounds like a very myopic solution to the issue you originally
>> raised, and I don't think it will solve the underlying issues.
>> 
>> Taking a step back, you originally raised a concern about how we
>> prioritize reviews with the havana-rc-potential tag.
>> [...]
> 
> I'm with Joe here. Additionally, I don't see how the proposed solution
> would solve anything for the original issue.
> 
> You propose letting a subteam approve incremental patches in a specific
> branch, and propose a big blob every milestone to merge in Nova proper,
> so that the result can be considered golden and maintained by the Nova
> team. So nova-core would still have to review it, since they put their
> name on it. I don't see how reviewing the big blob is a lot easier than
> reviewing incremental patches. Doing it under the time pressure of the
> upcoming milestone won't drive better results.
> 
I already replied on this in the following emails, it was a proposal based on all the feedbacks to try to find a common ground, surely not the best option.

> Furthermore, the issue you raised was with havana release candidates,
> for which we'd definitely not take the "big blob" approach anyway, and
> go incremental all the way.
> 
Ditto

> 
> The subsystem mechanism works for the Linux kernel due to a trust model.
> Linus doesn't review all patches coming from a subsystem maintainer, he
> developed a trust in the work coming from that person over the years.
> 
That's the only way to go IMO as the project gets bigger.

> The equivalent in the OpenStack world would be to demonstrate that you
> understand enough of the rest of the Nova code to avoid breaking it (and
> to follow new conventions and features added there). This is done by
> participating to reviews on the rest of the code. Then your +1s can be
> considered as +2s, since you're the domain expert and you are trusted to
> know enough of the rest of the code. That model works quite well with
> oslo-incubator, without needing a separate branch for every incubated API.
> 

How should a driver "break Nova"? It's 100% decoupled. The only contact area is the driver interface that we simply consume, without changing it.

In the very rare cases in which we propose changes to Nova code (only the RDP patch so far in 3 releases) that'd be of course part of the Nova project, not the driver.

Oslo-incubator is definitely not a good example here as its code gets consumed by the other projects.

A separate project would give no concerns on breaking anything, only users of that specific driver would install it, e.g.:

pip install nova-driver-hyperv

For the moment, our Windows code is included in every Linux release with OpenStack (Ubuntu, RH/CentOS+RDO, etc). I find it quite funny to be honest.

> Finally, the best way to not run into those priority hurdles is by
> anticipating them. Since hyper-V is not tested at the gate, reviewers
> will always be more reluctant in accepting late features and RC fixes
> that affect hyper-V code. Landing features at the beginning of a cycle
> and working on bugfixes well before we enter the release candidate
> phases... that's the best way to make sure your work gets in before release.
> 

What if a bug gets reported during the RC phase like it happened now? How can we work on it before it gets reported? Should I look for a crystal ball? :-)

Landing all features at the beginning of the cycle and spending the next 3 months to beg for reviews that won't add almost anything to the patches and without any guarantee that this will happen? That would simply mean being constantly one entire release late in the development cycle without any advantage.

Beside the blueprints, the big problem are with bug fixes. Once you have a fix, why waiting weeks before releasing it and getting users unhappy? 

As a an example we have a couple of critical bugs for Havana with their fix already under review that nobody cared even to triage, let alone review.

Considering that we are not singled out here, the only explanation is that the Nova team is simply not able to face anymore the increasing amount of bugs and new features, with the obvious negative impact on the users.

Let's face it: the Nova team cannot scale fast enough as the project size increases at this pace.

Delegation of responsibility on partitioned and decoupled areas is the only proven way out, as for example the Linux kernel project clearly shows.

Alessandro

> Regards,
> 
> -- 
> Thierry Carrez (ttx)
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev