Open Stack

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)