On 4 August 2015 at 21:23, Matt Riedemann <[email protected]> wrote: > > > On 8/4/2015 8:47 AM, Sahid Orentino Ferdjaoui wrote: >> >> On Tue, Aug 04, 2015 at 12:54:34PM +0200, Thierry Carrez wrote: >>> >>> John Garbutt wrote: >>>> >>>> [...] >>>> Personally I find a mix of coding and reviewing good to keep a decent >>>> level of empathy and sanity. I don't have time for any coding this >>>> release (only a bit of documenting), and its not something I can >>>> honestly recommend as a best practice. If people don't maintain a good >>>> level of reviews, we do tend to drop those folks from nova-core. >>>> >>>> I know ttx has been pushing for dedicated reviewers. It would be nice >>>> to find folks that can do that, but we just haven't found any of those >>>> people to date. >>> >>> >>> Hell no! I'd hate dedicated reviewers. >>> >>> [...] >>> This is why I advocate dividing code / reviewers / expertise along >>> smaller areas within Nova, so that new people can focus and become a >>> master again. What I'm pushing for is creating Nova subteams with their >>> own core reviewers, which would be experts and trusted to +2 on a >>> defined subset of code. >> >> >> Yep this makes a lot of sense and unfortunately we bring this idea >> every time but nothing seems to move in that way. >> >> Contributors working in Nova feel more and more frustrated. >> >> So specs got approved June 23-25 then about 15 working days to push >> all of the code and 12 working days to make it merged. From my >> experience working on Nova it's not possible. For instance on libvirt >> driver we have one core who does most of the reviews, but we have >> problem to find the +2/+W and without to mention problem when he >> is author of the fix [1]. >> >> We delay good features (with code pushed and waiting reviews) we can >> bring to users. I guess users are happy to hear that we are working >> hard to improve our code base but perhaps they also want features >> without to wait a year (3.1, 95, 98, me, xp...). >> >> And I know that because I'm working every days in Nova since more than >> 2 years - We have really skilled people who can help. >> >> [1] https://review.openstack.org/#/c/176360/ >> >> s. >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > Yeah so this thread is starting to devolve into scaling the core team again, > which is what I didn't want to happen. The goal was to talk about how we > can line up things in a backlog to still allow review and possible inclusion > to a release after the spec freeze cutoff, but not necessarily target > something for inclusion (like that rbd snapshot example), and not detract > from what has been approved before the spec freeze cutoff or other > priorities. > > I think I got the answer from John which is the path forward is starting to > kick the tires on some new tooling like phabricator and then doing some > things with runways / kanban boards so we don't have as rigid a process, we > just queue up things as they come. > > So I'm satisfied for now. >
So this push towards a kanban/runways style is going to be a big effort. Please do reach out if you are happy to help make that happen, I really do need help to make this happen quickly! It would be great to move over to runways like system sometime in Mitaka. I have hoped to do it in kilo-3, but its just not worked out that way :( Thanks, John __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
