Open Stack

On 7/3/15, 05:35, "Kuvaja, Erno" <kuvaja at hp.com> wrote:

>First of all, Thanks Flavio for bring this open to the daylight!

I agree. More of these discussions need to happen on the mailing list.

>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:flavio at redhat.com]
>> Sent: Wednesday, July 01, 2015 2:49 PM
>> To: openstack-dev at 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.

I agree we should also have at least a handful of specs already merged
along with some of the implementation patches for them. That said,
projects that are already freezing their spec repos tend to see many more
proposals for us.

>> 
>> 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?

So I think I agree with the movement other projects have been taking of
accepting a spec before the code is completed and reviewed and then moving
it to a list of "completed specs" once the code has been reviewed, merged,
etc.

>> 
>> 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.

So the trick with this is the following:

1. For the drivers team we need people who know glance well as both a
product and a codebase and have a clear idea of how both need to move
forward.
2. For the drivers team we need people who can also see the architectural
implications of specs in review.
(other things I'm probably forgetting).

It's hard to pick two or three people to just join the team in that case.

>> 
>> 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev