Open Stack

On 20/04/15 19:34 +0000, Kuvaja, Erno wrote:
>> -----Original Message-----
>> From: Flavio Percoco [mailto:flavio at redhat.com]
>> Sent: 20 April 2015 15:04
>> To: openstack-dev at lists.openstack.org
>> Subject: [openstack-dev] [Glance] Open glance-drivers to all glance-cores
>>
>> Hello Glance folks, and not Glance folks :D
>>
>> Here's a thought. I believe, based on the size of our
>> project/community/reviewers team, we should just give access to all glance-
>> cores to glance-drivers. Few considerations:
>>
>> 1) Many of our reviewers have been part of Glance even before I became
>> part of it. It just makes no sense to me that these folks that have put efforts,
>> time and that have helped making Glance what it is today don't have a voice
>> on the specs. Commenting seems to not be enough, apparently.
>>
>> 2) I'd like to encourage a more open communication in our specs review
>> process and including all our current *code* reviewers seems like a good
>> step forward towards that. Things that I'd love to thing and to avoid are:
>>
>>   - I'd love to avoid all kind of private emails/conversations. Specs
>>     can either be discussed in the review (which is what it's for),
>>     team meetings or mailing list.
>>
>>   - I'd love for specs to get more attention from other folks. In
>>     other words, I'd like to scale our specs review process. There are
>>     specs that have sitten there for a bit.
>>
>>   - Our *code* reviewers know Glance's code, I want them to have a way
>>     to express a stronger opinion/vote.
>>
>> 3) Although this doesn't seem to work for other projects, I believe Glance is
>> not such a big community for this to fail. If anything, it should help us to
>> manage the load a bit better. If there are core-reviewers that simply don't
>> want to do spec reviews, that's fine.
>>
>> 4) If there are non-core reviewers that want to be part of the glance-drivers
>> team then we can vote as we do for new cores. I have to admit that I'm
>> having a hard time to imagine a case like this but...
>> who knows? right?
>>
>> 5) It used to be like this and many of us just found themselves out of the
>> glance-drivers team without notice. It's probably an unexpected side effect
>> of disconnecting LP/gerrit and splitting the teams. Not a big deal, but...
>>
>> Thoughts?
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco
>
>Hi Flavio,
>
>Thanks for your trust towards us. While I think this is great gesture (specially towards us new members) I do not think this is exactly the "safest" option at the moment. We have had active discussion and steep learning curve to the specs over past cycle and I think we need to sort that out first. Second concern I have is that looking our core-reviewers now, we are actually fairly young group since the last flush (give or take half of us have been even core less than a year).
>
>I will jump bit around on this so please try to hang on. For your point 3) I do agree. I think we can get there fairly soon if that is what people wants, but as mentioned I'd like to get our processes cleared first.
>
>I'd like to address points 4 and 5 on single hit and _if_ we in future include whole core in the drivers we keep the drivers group still separated and individual members to that group nominated on similar open manner as we do for our cores.
>
>Now last but not least to your point 2) (sorry, I have really no input on 1)). I do strongly agree with you on this.  As the specs are supposed to be not just an overview of the proposed functionality but also touched quite deeply to the technical aspects and as you pointed out that would be great to engage more of the code folks to the specs, there would be room for stronger opinion.
>
>What I would propose as alternative instead of including glance-core to glance-drivers would be change in the acls of the glance-specs repo. How about we give -2..+2 vote to glance-core & glance-drivers and keep the workflow +1 on glance-drivers only? This would give us stronger say on the direction but would keep the decision of taking the spec out of review (merge) on the drivers until we can figure out/agree and _document_ how we are going to process the specs.

All good points and answers, Erno. Thanks!

By reading your email, I believe we both are, somehow, complaining
about our current spec review process. I believe it doesn't make sense
that most of our historical reviewers are not in the drivers team and
that their opinions are not *required* in some areas.

Specs pretty much define *where* the project is headed and while I
trust very much our current drivers team, I believe we need more
input. It may be argued that to provide input it's not necessary to be
in the team and have +2/-2 access but unfortunately, in some cases,
it's not been enough.

In Oslo, the oslo-core team is the one reviewing specs. The process,
roughly, is that we all review the specs and vote and then the PTL
approves it. I've followed this process in Glance too and I have not
approved a single spec, I've limited myself to just review and provide
feedback. Removing Workflow +/- could make sense but again, there are
few cases where having a couple of more people watching over that repo
is good.

I guess my point is that specs will be discussed anyway and only
people that have participated in the discussions for a specific spec
know what's going on and what should be done. Therefore, I believe
these people will keep shuch spec updated, the discussions open and
what ever happens with that spec will be decided by more than one
person. I'm, by any means, trying to imply anything here. I just want
to make a point and encourage simplicity and clarity/transparency in
our spec process.

I trust the core team enough to believe no-one is going to get in
approve mode on specs. ;)

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150421/791d22ee/attachment.pgp>