Open Stack

Mark McLoughlin wrote:
> [...]
> I don't see how any self-respecting open-source project can throw a
> release over the wall and have no ability to address critical bugs with
> that release until the next release 6 months later which will also
> include a bunch of new feature work with new bugs. That's not a distro
> maintainer point of view.

I agree that the job changed a bit since those early days, and now apart
from a very small group of stable specialists (mostly the stable release
managers), everyone else on stable-core is actually specialized in a
given project. It would make sense for each project to have a set of
dedicated "stable liaisons" that would work together with stable release
managers in getting critical bugfixes to stable branch point releases.
Relying on the same small group of people now that we have 10+ projects
to cover is unreasonable.

There are two issues to solve before we do that, though. The projects
have to be OK with taking on that extra burden (it becomes their
responsibility to dedicate resources to stable branches). And we need to
make sure the stable branch guidelines are well communicated.

> [...]
> That's quite a leap to say that -core team members will be so incapable
> of the appropriate level of conservatism that the branch will be killed.
> 
> The idea behind not automatically granting +2 on stable/* to -core
> members was simply we didn't want people diving in and approving
> unsuitable stuff out of ignorance.
> 
> I could totally see an argument now that everyone is a lot more familiar
> with gerrit, the concept of stable releases is well established and we
> should be able to trust -core team members to learn how to make the risk
> vs benefit tradeoffs needed for stable reviews.

The question here is whether every -core member on a project should
automatically be on stable-core (and we can reuse the same group) or do
we have to maintain two groups.

>From my experience reviewing stable branch changes, I see two types of
issues with regular core doing stable reviews. There is the accidental
stable/* review, where the person thinks he is reviewing a master
review. Gerrit makes it look extremely similar, so more often than not,
we have -core members wondering why they don't have +2 on review X, or
core members doing a code review (criticizing the code again) rather
than a stable review (checking the type of change and the backport).
Maybe we could solve that by making gerrit visually different on stable
reviews ?

And then there is the opportunistic review, where a core member bends
the stable rules because he wants a specific fix backported. So we get
database migrations, new configuration options, or default behavior
changes +1ed or +2ed in stable. When we discuss those on the review, the
-core person generally disagrees with the stable rules and would like
them relaxed.

This is why I tend to prefer an opt-in system where the core member
signs up to do stable review. He clearly says he agrees with the stable
rules and will follow them. He also signs up to do enough of them to
limit the opportunistic and accidental issues.

-- 
Thierry Carrez (ttx)