[Ksummit-discuss] [CORE TOPIC] stable workflow

Dmitry Torokhov dmitry.torokhov at gmail.com
Wed Aug 3 16:12:34 UTC 2016


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".

Thanks.

-- 
Dmitry


More information about the Ksummit-discuss mailing list