Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Stable trees and release time

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2018-09-05 at 10:32 +0200, Jiri Kosina wrote:
> On Wed, 5 Sep 2018, Jan Kara wrote:
> 
> > So I agree that with current amount of patches in stable tree, the 
> > review is cursory at best. However that does not really seem to be 
> > related to the frequency of stable releases (which is what I
> > believe  Laura complains about in this thread) but rather to the
> > amount of 
> > patches going into stable.
> 
> I think the psychological aspect shouldn't be ignored in this
> particular  case.

This really shouldn't be an issue: stable trees are backported from
upstream.  The patch (should) work in upstream, so it should work in
stable.  There are only a few real cases you need to worry about:

   1. Buggy patch in upstream backported to stable. (will be caught and
      the fix backported soon)
   2. Missing precursor causing issues in stable alone.
   3. Bug introduced when hand applying.

The chances of one of these happening is non-zero, but the criteria for
stable should mean its still better odds than the odds of hitting the
bug it was fixing.

This is the thing: backporting is an expediency process, not a perfect
process.  We are going to get bugs with backports, we just make sure
the backport is for an issue serious enough that on balance we reduce
the bugginess of the stable kernels.

> Maintainers and patch authors being constantly flooded by stable
> queues would never really get back to reviewing it, as it's always
> there, more is  already in flight, and the previous pile is still
> unreviewed.
> 
> If it comes at regular pace though, it's a bit easier to align with
> it and establish for example "friday afternoon stable review 2 hours"
> into maintainer's workflow :)
> 
> But yeah, it's weak and doesn't solve the primary thing, which is
> just the  size of stable itself.

Look, this just isn't going to happen.  As a maintainer I'm going to
see the backport, think it fixed a bug in upstream and stop there. 
That's no better review than you get by insisting that the patch be
upstream first.  Can we embrace this as the actual review in upstream
process and move on?

As I said there's a small but non-zero chance of bugs because of the
issues listed above, but I'm not going to spot them even if I performed
a full review for a kernel I forgot about months ago.

James