On Tue, Nov 3, 2015 at 5:49 PM, Ihar Hrachyshka <[email protected]> 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? > +1 > > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
