<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 November 2015 at 08:49, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi all,<br>
<br>
currently we have a single neutron-wide stable-maint gerrit group that<br>
maintains all stable branches for all stadium subprojects. I believe<br>
that in lots of cases it would be better to have subproject members to<br>
run their own stable maintenance programs, leaving<br>
neutron-stable-maint folks to help them in non-obvious cases, and to<br>
periodically validate that project wide stable policies are still honore<br>
d.<br>
<br>
I suggest we open gate to creating subproject stable-maint teams where<br>
current neutron-stable-maint members feel those subprojects are ready<br>
for that and can be trusted to apply stable branch policies in<br>
consistent way.<br>
<br>
Note that I don't suggest we grant those new permissions completely<br>
automatically. If neutron-stable-maint team does not feel safe to give<br>
out those permissions to some stable branches, their feeling should be<br>
respected.<br>
<br>
I believe it will be beneficial both for subprojects that would be<br>
able to iterate on backports in more efficient way; as well as for<br>
neutron-stable-maint members who are often busy with other stuff, and<br>
often times are not the best candidates to validate technical validity<br>
of backports in random stadium projects anyway. It would also be in<br>
line with general 'open by default' attitude we seem to embrace in<br>
Neutron.<br>
<br>
If we decide it's the way to go, there are alternatives on how we<br>
implement it. For example, we can grant those subproject teams all<br>
permissions to merge patches; or we can leave +W votes to<br>
neutron-stable-maint group.<br>
<br>
I vote for opening the gates, *and* for granting +W votes where<br>
projects showed reasonable quality of proposed backports before; and<br>
leaving +W to neutron-stable-maint in those rare cases where history<br>
showed backports could get more attention and safety considerations<br>
[with expectation that those subprojects will eventually own +W votes<br>
as well, once quality concerns are cleared].<br>
<br>
If we indeed decide to bootstrap subproject stable-maint teams, I<br>
volunteer to reach the candidate teams for them to decide on initial<br>
lists of stable-maint members, and walk them thru stable policies.<br>
<br>
Comments?<br></blockquote><div><br></div><div>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.... :)</div><div><br></div><div>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</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Would that strike a better middle ground?</div><div><br></div><div>Kyle, Russell and I have talked during the summit about clarifying the meaning of the stadium. Stable backports falls into this category, and I am glad you brought this up.</div><div><br></div><div>Cheers,</div><div>Armando</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Ihar<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQEcBAEBAgAGBQJWOOWkAAoJEC5aWaUY1u57sVIIALrnqvuj3t7c25DBHvywxBZV<br>
tCMlRY4cRCmFuVy0VXokM5DxGQ3VRwbJ4uWzuXbeaJxuVWYT2Kn8JJ+yRjdg7Kc4<br>
5KXy3Xv0MdJnQgMMMgyjJxlTK4MgBKEsCzIRX/HLButxcXh3tqWAh0oc8WW3FKtm<br>
wWFZ/2Gmf4K9OjuGc5F3dvbhVeT23IvN+3VkobEpWxNUHHoALy31kz7ro2WMiGs7<br>
GHzatA2INWVbKfYo2QBnszGTp4XXaS5KFAO8+4H+HvPLxOODclevfKchOIe6jthH<br>
F1z4JcJNMmQrQDg1WSqAjspAlne1sqdVLX0efbvagJXb3Ju63eSLrvUjyCsZG4Q=<br>
=HE+y<br>
-----END PGP SIGNATURE-----<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>