Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 18/08/14 11:00, Thierry Carrez wrote:
> 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.

Indeed, not everyone feels safe when reviewing stable backports for
projects he is not really involved in. For example, I'm more or less
fine with Neutron and Oslo, and some Nova patches, but once it gets to
e.g. Horizon or Keystone, I feel very worried that I even have +2 for
those branches, and generally don't apply it unless I'm completely
sure the fix is obvious, and the bug is clear for outsider (=me).

The problem is that some projects lack people that are both confident
in the code base and are dedicated to support stable maint effort. So
while Neutron or Nova do not feel great deficit in the number of
maintainers who care about their stable branches, for other projects
it may be really hard to find anyone to review the code.

Dedicated liasons would solve that.

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

I would be glad if stable patches are not shown by default in queries
unless explicitly requested. That would solve the issue of people
reviewing the code of backports, and others.

I would also like to have some way to explicitly mark a stable branch
patch as being 'not a trivial cherry-pick'. Sometimes stable branch
patches are not really similar to their original master fellows. Or
even we need to push a stable branch only patch because the issue or
the affected code is not in master. In that case, stable maintainers
are not the ones to do review, because the code should be checked by
the real cores of the affected projects, and checking technical
details and general applicability of the patch for stable branch is
not enough. Something like a button to mark the backport as requiring
special attention from cores.

Both the split and a way to drive cores' attention to specific
backport would remove burden from both project cores and stable
maintainers that sometimes struggle to review non-trivial bug fixes.

> 
> 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.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJT8dfWAAoJEC5aWaUY1u57f30H/0IA9QaXV0U8f9QtkFQJpAF/
/3gK/ZRXQsXYd0/puMldPH5Q5Kx0GAvI0sBFBkjdxTlaXjmhwvobr97lE52wHyiN
08HPipxLj3cUs31H77r+VcbejFbozWK1g3c7gH4DcaY7vNA6Mt9GeHwUV/T/coIL
k/p50hAd6H6Z7YBi380OduA3Rqdph70pXGgiRuPfB83KxdzwmPNMNq+J94EwLbOZ
0WbsS+IkJBpWPSgwZTSb2oi3HVX/75DUGTgLr+1srq3EXyWUSFafI9/+FupUpZ/f
DdqXjUkVhYEu6imBOCFO61DkfE5eQ3zkFIjpp7nVOhPtFYc5VrSYJKWYrJr5Ez0=
=CI75
-----END PGP SIGNATURE-----