Open Stack

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 <mestery at mestery.com> wrote:

> On Tue, Nov 3, 2015 at 10:49 AM, Ihar Hrachyshka <ihrachys at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151103/cbd4f170/attachment.html>