First of all, Thanks Flavio for bring this open to the daylight! I have been really frustrated about the Glance spec process since the beginning and as glance core tried to work around the limitations the best I can. I'm not sure if the process is similar way broken on the other projects, but I think after piloting the process in Glance for couple of cycles we should take some action on it.
Few comments inline as that way they are easier to scope. > -----Original Message----- > From: Flavio Percoco [mailto:fla...@redhat.com] > Sent: Wednesday, July 01, 2015 2:49 PM > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [glance] The sorry state of our spec process > > Greetings, > > We're 1 week through L-2 (or is it 2?, I can't do time) and we, the glance > project, haven't even merged a single spec. Regardless of the reasons > behind this situation and the fact that we've been indeed taking steps to > improve this situation, I think we should put this issue to an end. This is really sad state to be in. We haven't approved a single spec by the time other projects are already freezing their spec repos for L. > > There are many issues we've faced in Glance: > > 1. The glance-drivers team is too small [0] 2. Many specs have been held back > waiting for code [1] 3. Huge expectations from the spec and very low review > rate (even from other members of the glance team). This issue was discussed while ago and was postponed to clarify the Glance Spec process. After that this is first initiative to bring the issue back to table and I'd like to hear if that process defining work is still blocking the expansion to share the workload. If so, could we please get the proposal of that workload or at least the parts of it that needs to be ironed out open in public so we can move that forward as community? > > There was a recent discussion on this m-l[2] about the spec process in Nova > and while I don't agree with everything that was said there, I do think it > highlights important problems that we're facing in glance as well. > > Therefore, I'd like to propose the following: > > 1. Expand our drivers team. I thik people in the glance community are getting > annoyed of reading this requests from me and "The Mythical Man-Month" > would agree with them. However, it's really sad that some of our oldest (in > terms of tenure) contributors that have shown interest in joining the team > haven't been added yet. I proposed to bring all cores to the drivers team > already and I still think that's a good thing. Assuming that's something we > don't want, then I'd like us to find 2 or 3 people willing to volunteer for > this > task. If this still "cannot" happen I'd like to get full commitment from our current drivers to dedicate the time and effort for speedy workflow on our specs or step down and trash the whole spec process. > > 2. Lets try to get things into the backlog instead of expecting them to be > perfectly shaped and targeted for this release. Lets let people start from a > base, generally agreed, idea so that code can be written and reviews on the > actual feature can be made. Once the feature is implemented, we can move > the spec to the release directory. I believe this was also proposed in > Nikola's > thread[2]. I'm huge supporter of this. Specs being part of our normal review workflow makes changing them as needed easy and trackable. Why in earth we need to have perfect plan and implementation for that plan before we're willing to indicate approval for the initial idea? > > 3. Not all specs need to have 3-month-long discussions to be approved. > I'm not suggesting to just merge specs that are in poor state but we can't > always ask for code to understand whether a spec makes sense or not. > > Unfortunately, we're already in L-2 and I believe it'll be really hard for > some > of those features to land in Liberty, which is also sad and quite a waste of > time. How long we will have people trying to improve the project if any given proposed functionality takes cycles and lots of politics to merge. > > I don't believe the above is the ultimate solution to this issue but I > believe it > will help. For the next cycle, we really need to organize this process > differently. ++ - Erno > > The email is already long enough so, I hope we'll agree on something and > finally take some actions. > > Cheers, > Flavio > > [0] https://review.openstack.org/#/c/126550/ > [1] https://review.openstack.org/#/admin/groups/342,members > (Mark Washenberger and Arnaud Legendre are not contributors anymore) > [2] http://lists.openstack.org/pipermail/openstack-dev/2015- > June/067861.html > > > -- > @flaper87 > Flavio Percoco __________________________________________________________________________ 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
