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. 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