<div dir="ltr">This plan makes a lot of sense to me.<div>With the staggering number of sub-projects in neutron it is impossible for the stable team to cope with the load. Delegation and decentralisation is a must and both sub-project maintainers and the stable team will benefit from it.</div><div>Also, since patches can always be reverted and rights revoked in case of misbehaviour I do not see any major downside.<br></div><div>I am sure the stable maint team will periodically monitor what's being backported in order to intervene quickly if backport policies are violated.</div><div><br></div><div>Salvatore</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 November 2015 at 18:09, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Tue, Nov 3, 2015 at 10:49 AM, 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:0 0 0 .8ex;border-left:1px #ccc 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>
<br></blockquote><div><br></div></div></div><div>As someone who spends a considerable amount of time reviewing stable backports on a regular basis across all the sub-projects, I'm in favor of this approach. I'd like to be included when selecting teams which are approproate to have their own stable teams as well. Please include me when doing that.<br><br></div><div>Thanks,<br></div><div>Kyle<br></div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></span></div><br></div></div>
<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>
<br></blockquote></div><br></div>