This plan makes a lot of sense to me. 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. Also, since patches can always be reverted and rights revoked in case of misbehaviour I do not see any major downside. I am sure the stable maint team will periodically monitor what's being backported in order to intervene quickly if backport policies are violated.
Salvatore On 3 November 2015 at 18:09, Kyle Mestery <mest...@mestery.com> wrote: > On Tue, Nov 3, 2015 at 10:49 AM, Ihar Hrachyshka <ihrac...@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? >> >> > 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. > > Thanks, > Kyle > > >> Ihar >> -----BEGIN PGP SIGNATURE----- >> >> iQEcBAEBAgAGBQJWOOWkAAoJEC5aWaUY1u57sVIIALrnqvuj3t7c25DBHvywxBZV >> tCMlRY4cRCmFuVy0VXokM5DxGQ3VRwbJ4uWzuXbeaJxuVWYT2Kn8JJ+yRjdg7Kc4 >> 5KXy3Xv0MdJnQgMMMgyjJxlTK4MgBKEsCzIRX/HLButxcXh3tqWAh0oc8WW3FKtm >> wWFZ/2Gmf4K9OjuGc5F3dvbhVeT23IvN+3VkobEpWxNUHHoALy31kz7ro2WMiGs7 >> GHzatA2INWVbKfYo2QBnszGTp4XXaS5KFAO8+4H+HvPLxOODclevfKchOIe6jthH >> F1z4JcJNMmQrQDg1WSqAjspAlne1sqdVLX0efbvagJXb3Ju63eSLrvUjyCsZG4Q= >> =HE+y >> -----END PGP SIGNATURE----- >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev