Open Stack

Armando M. <armamig at gmail.com> wrote:

> On 3 November 2015 at 08:49, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi all,
>>
>> currently we have a single neutron-wide stable-maint gerrit group that
>> maintains all stable branches for all stadium subprojects. I believe
>> that in lots of cases it would be better to have subproject members to
>> run their own stable maintenance programs, leaving
>> neutron-stable-maint folks to help them in non-obvious cases, and to
>> periodically validate that project wide stable policies are still honore
>> d.
>>
>> I suggest we open gate to creating subproject stable-maint teams where
>> current neutron-stable-maint members feel those subprojects are ready
>> for that and can be trusted to apply stable branch policies in
>> consistent way.
>>
>> Note that I don't suggest we grant those new permissions completely
>> automatically. If neutron-stable-maint team does not feel safe to give
>> out those permissions to some stable branches, their feeling should be
>> respected.
>>
>> I believe it will be beneficial both for subprojects that would be
>> able to iterate on backports in more efficient way; as well as for
>> neutron-stable-maint members who are often busy with other stuff, and
>> often times are not the best candidates to validate technical validity
>> of backports in random stadium projects anyway. It would also be in
>> line with general 'open by default' attitude we seem to embrace in
>> Neutron.
>>
>> If we decide it's the way to go, there are alternatives on how we
>> implement it. For example, we can grant those subproject teams all
>> permissions to merge patches; or we can leave +W votes to
>> neutron-stable-maint group.
>>
>> I vote for opening the gates, *and* for granting +W votes where
>> projects showed reasonable quality of proposed backports before; and
>> leaving +W to neutron-stable-maint in those rare cases where history
>> showed backports could get more attention and safety considerations
>> [with expectation that those subprojects will eventually own +W votes
>> as well, once quality concerns are cleared].
>>
>> If we indeed decide to bootstrap subproject stable-maint teams, I
>> volunteer to reach the candidate teams for them to decide on initial
>> lists of stable-maint members, and walk them thru stable policies.
>>
>> Comments?
>
> It was like this in the past, then it got changed, now we're proposing of
> changing it back? Will we change it back again in 6 months time? Just
> wondering.... :)

Neutron: it’s all about change!

Jokes aside, I don’t believe we were in this situation before. I think once  
we started to spin off subprojects, it was always the case that only  
neutron-stable-maint members are allowed to +2 or +A for all stable  
branches for all subprojects, both ‘core’ and ‘stadium’.

>
> I suppose this has to do with the larger question of what belonging to the
> stadium really means. I guess this is a concept that is still shaping up,
> but if the concept is here to stay, I personally believe that being part of
> the stadium means adhering to a common set of practices and principles
> (like those largely implemented in OpenStack) where all projects feel and
> behave equally. We have evidence where a few feel that 'stable' is not a
> concept worth honoring and for that reason I am wary to relax this

Indeed, if any change occurs, it should not relax expectations. That’s why  
I would like us to be picky about which teams could get their stable  
groups, and which of them have not proved yet their commitment to the  
project wide stable criteria.

I agree that stable initiative should be discussed in context of larger  
stadium requirements.

F.e. we have subprojects that do not have decent test coverage, that  
nevertheless continue to band-aid bugs in their code with more fixes that  
do not include tests. Those bug fixes are sometimes proposed for backports.  
I believe decent testing coverage should be a requirement for any stadium  
project, something that could result in dropping from stadium if not  
achieved in reasonable time.

>
> I suppose it could be fine to have a probation period only to grant full
> rights later on, but who is going to police that? That's a job in itself.
> Once the permission is granted are we ever really gonna revoke it? And what
> does this mean once the damage is done?
>

I presume it does not differ from current trust model used in  
neutron-stable-maint: folks get their votes and are generally not  
explicitly supervised. If issues will arise, yes, we would need to revoke  
voting rights and clean up the mess. Yes, for vendor repositories there is  
a slight difference, since there is no real external visibility, as we have  
in other vendor-agnostic teams.

> Perhaps an alternative could be to add a selected member of each subproject
> to the neutron-stable-maint, with the proviso that they are only supposed
> to +2 their backports (the same way Lieutenant is supposed to +2 their
> area, and *only their area* of expertise), leaving the +2/+A to more
> seasoned folks who have been doing this for a lot longer.
>
> Would that strike a better middle ground?
>

That could be an option, though I don’t see how it’s really different from  
having separate teams that are *not* granted +A vote (so you would need  
neutron-stable-maint member to merge the change). I believe infra allows  
such setup.

Putting everyone in the same neutron-stable-maint group has some issues.  
For the start, it opens doors to violations that affect core projects;  
second, it makes ‘real' neutron-stable-maint team less distinguishable.  
Often times when I need to make a patch in e.g. lbaas to get in quickly, I  
go to gerrit and search for the appropriate group for the project to see  
the list of folks that have merge access there. I believe some people may  
rely on the same practice when it comes to backports. Having all vendor  
folks in the same group will leave it unclear who is really meant to  
supervise all stable branches, and who got his membership purely for a  
single stadium repo.

However we implement it, I am also good with granting just +2 to stadium  
teams, and leaving decisive merge action to seasoned folks. Once there, we  
will be able to reassess the next steps, if we feel like it.

Ihar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151105/714afecb/attachment.pgp>