Re: [openstack-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams?
On Tue, Nov 3, 2015 at 5:49 PM, Ihar Hrachyshkawrote: > -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: 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
Re: [openstack-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams?
Armando M.wrote: On 3 November 2015 at 08:49, Ihar Hrachyshka 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? It was like this in the past, then it got changed, now we're proposing of changing it back? Will we change it back again in 6 months time? Just wondering :) Neutron: it’s all about change! Jokes aside, I don’t believe we were in this situation before. I think once we started to spin off subprojects, it was always the case that only neutron-stable-maint members are allowed to +2 or +A for all stable branches for all subprojects, both ‘core’ and ‘stadium’. I suppose this has to do with the larger question of what belonging to the stadium really means. I guess this is a concept that is still shaping up, but if the concept is here to stay, I personally believe that being part of the stadium means adhering to a common set of practices and principles (like those largely implemented in OpenStack) where all projects feel and behave equally. We have evidence where a few feel that 'stable' is not a concept worth honoring and for that reason I am wary to relax this Indeed, if any change occurs, it should not relax expectations. That’s why I would like us to be picky about which teams could get their stable groups, and which of them have not proved yet their commitment to the project wide stable criteria. I agree that stable initiative should be discussed in context of larger stadium requirements. F.e. we have subprojects that do not have decent test coverage, that nevertheless continue to band-aid bugs in their code with more fixes that do not include tests. Those bug fixes are sometimes proposed for backports. I believe decent testing coverage should be a requirement for any stadium project, something that could result in dropping from stadium if not achieved in reasonable time. I suppose it could be fine to have a probation period only to grant full rights later on, but who is going to police that? That's a job in itself. Once the permission is granted are we ever really gonna revoke it? And what does this mean once the damage is done? I presume it does not differ from current trust model used in neutron-stable-maint: folks get their votes and are generally not explicitly supervised. If issues will arise, yes, we would need to revoke voting rights and clean up the mess. Yes, for vendor repositories there is a slight difference, since there is no real external visibility, as we have in other vendor-agnostic teams. Perhaps an alternative could be to add a selected member of each subproject to the neutron-stable-maint, with the proviso that they are only supposed to +2 their backports (the same way Lieutenant is supposed to +2 their area, and *only their area* of expertise), leaving the +2/+A to more seasoned folks who have been doing
Re: [openstack-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams?
On 3 November 2015 at 08:49, Ihar Hrachyshkawrote: > -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? > It was like this in the past, then it got changed, now we're proposing of changing it back? Will we change it back again in 6 months time? Just wondering :) I suppose this has to do with the larger question of what belonging to the stadium really means. I guess this is a concept that is still shaping up, but if the concept is here to stay, I personally believe that being part of the stadium means adhering to a common set of practices and principles (like those largely implemented in OpenStack) where all projects feel and behave equally. We have evidence where a few feel that 'stable' is not a concept worth honoring and for that reason I am wary to relax this I suppose it could be fine to have a probation period only to grant full rights later on, but who is going to police that? That's a job in itself. Once the permission is granted are we ever really gonna revoke it? And what does this mean once the damage is done? Perhaps an alternative could be to add a selected member of each subproject to the neutron-stable-maint, with the proviso that they are only supposed to +2 their backports (the same way Lieutenant is supposed to +2 their area, and *only their area* of expertise), leaving the +2/+A to more seasoned folks who have been doing this for a lot longer. Would that strike a better middle ground? Kyle, Russell and I have talked during the summit about clarifying the meaning of the stadium. Stable backports falls into this category, and I am glad you brought this up. Cheers, Armando > > 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
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
Re: [openstack-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams?
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
Re: [openstack-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams?
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 Mesterywrote: > On Tue, Nov 3, 2015 at 10:49 AM, Ihar Hrachyshka > 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
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 Hrachyshkawrote: > -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-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams?
-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? 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