On Wed, Jul 30, 2014 at 7:52 AM, Thierry Carrez <thie...@openstack.org> wrote: > Russell Bryant wrote: >> On 07/29/2014 12:12 PM, Daniel P. Berrange wrote: >>> Sure there was some debate about what criteria were desired acceptance >>> when stable trees were started. Once the criteria are defined I don't >>> think it is credible to say that people are incapable of following the >>> rules. In the unlikely event that people were to willfully ignore the >>> agreed upon rules for stable tree, then I'd not trust them to be part >>> of a core team working on any branch at all. With responsibility comes >>> trust and an acceptance to follow the agreed upon processes. >> >> I agree with this. If we can't trust someone on *-core to follow the >> stable criteria, then they shouldn't be on *-core in the first place. >> Further, if we can't trust the combination of *two* people from *-core >> to approve a stable backport, then we're really in trouble. > > There are a few different facets on this issue. > > The first facet is a community aspect. Stable branch maintenance is a > task separate from upstream development, ideally performed by the people > that have a direct interest in having good, maintained stable branches > (downstream distribution packagers). Now, if *all PTLs* are fine with > adding stable branch maintenance to the tasks of their core reviewers > (in addition to specs and master branch review), then I guess we can > abandon that concept of separate tasks. But I wasn't under the > impression the core population was looking forward to add extra duties > to their current workload. > Speaking as a PTL, I don't think adding all core team members for projects as stable maintainers would be a good thing. As pointed out already in this thread, the task of code reviews for stable is much different than that of code review for master. Having a more focused group of stable reviewers is likely a better solution than adding a large group of reviewers focused on upstream work. Also, as Sean pointed out in a followup email here, we have a process for people to propose themselves to stable maintenance [1]. Perhaps we need to publicize that a bit more to get more people who can actively help in the stable reviews to join the team.
Thanks, Kyle [1] https://wiki.openstack.org/wiki/StableBranch#Joining_the_Team > The second facet is the opt-in nature of the job. Yes, core reviewers > are trusted with acceptation of patches on the master branch and > probably have the capacity to evaluate stable branch patches as well. > But stable branches have different rules, and most current core > reviewers don't know them. There have been numerous cases where an > inappropriate patch was pushed to stable/* by a core developer, who was > very insistent on having his bugfix merged and rejected the "rules" we > were opposing to them. I'm fine with adding core reviewers which have > read and agreed to follow the stable rules, but adding them all by > default sounds more like a convenient way to push your own patches in > than a way to solve the stable manpower issue. > > The third facet is procedural: we currently have a single stable-maint > team for all integrated projects. The original idea is that the stable > branch maintainers do not judge the patch itself (which was judged by > -core people when the patch landed in master), they just judge if it's > appropriate for stable backport (how disruptive it is, if it's feature-y > or if it adds a new config option, or if it changes default behavior). > You don't need that much to be a domain expert to judge that, and if > unsure we would just ask. If we add more project-specific core > reviewers, we should probably switch to per-project stable-maint groups. > I'm not opposed to that, just saying that's an infra config change we > need to push. > > I'm generally open to changing that, since I reckon we have a manpower > issue on the stable maint side. I just want to make sure everyone knows > what they are signing up for here. We would do it for all the projects, > we can't special-case Nova. > > -- > Thierry Carrez (ttx) > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
