On 10/14/2013 04:10 AM, Thierry Carrez 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. > > 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.
Regarding the "original issue", I actually try very hard to stay on top of how nova is doing with the review queue. I wrote about this in detail in my PTL candidacy (see "Code Review Process" of [1]). I still maintain that the problem with review times is not quite as bad as some people make it out to be now and then. If there's an angle I'm not tracking, I would love help adding more to these stats. Of course, there's probably also quite a bit of variety in expectations. Perhaps we could do a better job of communicating what is a reasonable expectation when posting reviews. Note that the times look worse than usual right now, but that's explained by a bunch of patches that were blocked by the feature freeze being restored, and it looks like they've been waiting for review the whole time, even though they were abandoned for a while. http://russellbryant.net/openstack-stats/nova-openreviews.html > 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. While we don't have a MAINTAINERS file, I feel that we do this for Nova today. I do not expect everyone on nova-core to be an expert across the whole tree. Part of being on the core team is a trust in your reviews that you would only +2 stuff that you are comfortable with. [1] http://lists.openstack.org/pipermail/openstack-dev/2013-September/015370.html -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
