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. 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. 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. 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. 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. Regards, -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
