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) _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev