[Ksummit-discuss] [CORE TOPIC] stable workflow

[Guenter Roeck]

On 08/03/2016 09:12 AM, Dmitry Torokhov wrote:
> On Wed, Aug 03, 2016 at 08:48:34AM -0700, Guenter Roeck wrote:
>> On 08/03/2016 07:45 AM, Jiri Kosina wrote:
>>> On Wed, 3 Aug 2016, Greg KH wrote:
>>>
>>>>> Has anything changed in the process that'd just make patches like this one
>>>>> to be not merged these days?
>>>>
>>>> We have Guenter's test-bot that has helped out immensely here with this.
>>>
>>> That's very good to know, I admit that I have close to zero idea about how
>>> the stable -rcs are being tested.
>>>
>>
>> ... and when it doesn't work because I messed it up, we get issues such as 3.18
>> and 4.1 being broken for mips and sparc64 because a couple of patches which don't
>> apply to those kernels were tagged with an unqualified Cc: stable and applied.
>>
>> So, if anything, the one problem I see with the current stable process is
>> those unqualified stable tags. Maybe those should be deprecated; expecting
>> stable maintainers to figure out if a patch applies to a given stable branch
>> or not is a bit too much to ask for. With stable releases as far back as
>> 3.2 (or 338,020 commits as of right now) it is almost guaranteed that a
>> patch tagged with an unqualified Cc: stable doesn't apply to all branches.
>
> When I put cc:stable it is simply a suggestion for stable maintainers to
> figure out if this commit is suitable for _their_ stable. I might have
> an idea about n-1.x stable series but I certainly do not have any desire
> nor time to research whether this patch applicable to 3.2 or 3.0 stable
> series.
>
> Stable maintaintership should be more than "swipe in everything marked
> as cc:stable, try compiling and hope it all good".
>

I don't think I can agree to that. Personally I see it as my responsibility
to give stable maintainers as much information as possible. Dave for networking
goes even further, essentially providing stable maintainers with the patches
to apply (granted, I have no idea how he finds the time to do that).

How can one reasonable expect a stable maintainer to determine if a patch for
an oddball architecture applies, or one for a random subsystem ? Following
your argument, stable maintainers would have to be experts on all architectures
and subsystems in the kernel - because that is what they would have to be
in order to do more than "it compiles, therefore it works". Even compilation
is difficult - I suspect I might run the only testbed which builds _all_
supported architectures and runs qemu tests on 14 of them (not counting le/be
and 32/64 bit variants).

Guenter