On Fri, Feb 27, 2015 at 4:02 AM, Daniel P. Berrange <berra...@redhat.com> wrote:
> On Fri, Feb 27, 2015 at 09:51:34AM +1100, Michael Still wrote: > > On Fri, Feb 27, 2015 at 9:41 AM, Stefano Maffulli <stef...@openstack.org> > wrote: > > > > > Does it make sense to purge old stuff regularly so we have a better > > > overview? Or maybe we should chart a distribution of age of proposed > > > changesets, too in order to get a better understanding of where the > > > outliers are? > > > > Given the abandon of a review isn't binding (a proposer can easily > > unabandon), I do think we should abandon more than we do now. The > > problem at the moment being that its a manual process which isn't much > > fun for the person doing the work. > > > > Another factor to consider here is that abandoned patches against bugs > > make the bug look like someone is working on a fix, which probably > > isn't the case. > > > > Nova has been trying some very specific things to try and address > > these issues, and I think we're improving. Those things are: > > > > * specs > > * priority features > > This increased level of process in Nova has actually made the negative > effects of the 6 month cycle noticably worse on balance. If you aren't > able to propose your feature in the right window of the dev cycle your > chances of getting stuff merged has gone down significantly and the time > before users are likely to see your feature has correspondingly gone up. > Previously people could come along with simple features at the end of > the cycle and we had the flexibility to be pragmmatic and review and > approve them. Now we're lacking them that ability even if we have the > spare review cycles to consider it. The processes adopted have merely > made us more efficient at disappointing contributors earlier in the > cycle. There's been no changes made that would solve the bigger problem > of the fact that Nova is far too large vs the size of the core review > team, so we have a ongoing major bottleneck in our development. That, > bottleneck combined with the length of the 6 month cycle is an ongoing > disaster for our contributors. > > This is part of the reason we have moved to split Neutron into smaller, bite-sized chunk repositories with sometimes overlapping core reviewer teams. It's also why we're spinning out the backend logic from in-tree drivers and plugins to allow faster iteration for the maintainers. Early evidence indicates this has been succesful, we'll see how it looks once we get into the Liberty development cycle. For a bit more context, you can see the blog I wrote on this [1]. Thanks, Kyle [1] http://www.siliconloons.com/posts/2015-02-26-scaling-openstack-neutron-development/ Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ > :| > |: http://libvirt.org -o- http://virt-manager.org > :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ > :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc > :| > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
