Armando M. <arma...@gmail.com> wrote:
On 3 November 2015 at 08:49, 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?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 this for a lot longer. Would that strike a better middle ground?
That could be an option, though I don’t see how it’s really different from having separate teams that are *not* granted +A vote (so you would need neutron-stable-maint member to merge the change). I believe infra allows such setup.
Putting everyone in the same neutron-stable-maint group has some issues. For the start, it opens doors to violations that affect core projects; second, it makes ‘real' neutron-stable-maint team less distinguishable. Often times when I need to make a patch in e.g. lbaas to get in quickly, I go to gerrit and search for the appropriate group for the project to see the list of folks that have merge access there. I believe some people may rely on the same practice when it comes to backports. Having all vendor folks in the same group will leave it unclear who is really meant to supervise all stable branches, and who got his membership purely for a single stadium repo.
However we implement it, I am also good with granting just +2 to stadium teams, and leaving decisive merge action to seasoned folks. Once there, we will be able to reassess the next steps, if we feel like it.
Ihar
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ 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
