This seems we will get some more velocity which is good!! +1 German
From: Gary Kotton <gkot...@vmware.com<mailto:gkot...@vmware.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, November 4, 2015 at 5:24 AM To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams? From: "mest...@mestery.com<mailto:mest...@mestery.com>" <mest...@mestery.com<mailto:mest...@mestery.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, November 3, 2015 at 7:09 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams? On Tue, Nov 3, 2015 at 10:49 AM, Ihar Hrachyshka <ihrac...@redhat.com<mailto: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. +1 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://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