Open Stack

On Wed, Jul 30, 2014 at 7:52 AM, Thierry Carrez <thierry at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev