[Ksummit-discuss] [CORE TOPIC] stable workflow

[Guenter Roeck]

On 07/09/2016 02:36 AM, Mark Brown wrote:
> On Sat, Jul 09, 2016 at 10:43:05AM +0200, Jiri Kosina wrote:
>
>> If maintainers are overwhelmed by extra work needed for stable,
>> "offloading to Greg" doesn't sound like a proper solution to me at all.
>> "Fixing a maintainer workflow for that particular subsystem" (such as
>> extending the group of maintainers) does.
>
> I think one of the big things we're missing here is QA.  I don't
> personally have the hardware that would allow me to test a huge chunk of
> the code in my subsystems, I'm relying on things like kernelci.org for
> the bulk of it.  There's some work going on on getting Greg's stable
> queue tested more which will hopefully make things better but it's not
> 100% there yet.
>
Improving QA is very much part of it. Yes, there is kernelci.org, there is
kerneltest.org, there are the 0day builders, and there are various individuals
testing the trees. This all helped a lot in stabilizing both mainline and
the stable trees, but is not enough. We are pretty well covered with build
tests, but runtime tests are for the most part limited to "it boots, therefore
it works". We still have a long way to go to get real QA testing. As I
suggested earlier, we'll have to find a way to convince companies to actively
invest in QA.

> There's also the volume of stable trees to consider here - we've got a
> large number of stable trees which seem to be maintained in different
> ways with different tooling.  One big advantage from my point of view
> as a maintainer with the current model is that I don't have to figure
> out which I care about or anything like that.
>
The proliferation of stable trees (or rather, how to avoid it) might be
one of the parts of the puzzle. Yes, there are way too many right now.

Guenter