lkml.org 
[lkml]   [2019]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 5.3-rc7
On Sat, Sep 07, 2019 at 02:13:22PM -0700, Linus Torvalds wrote:
>On Sat, Sep 7, 2019 at 1:44 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> That's what I just replied to Chris. Can you do it right away or should I queue it up?
>
>Done.

I'd like to bring back a discussion we had last year on ksummit-discuss:
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2018-May/005122.html
. I've pointed out that some of the commits that go in the -rc cycles
are of low quality and are untested, you seemed to agree but said that
it's "by-design" because late -rc cycle commits are more complex.

Is this commit and it's fallout really how our development process
should be working?

This commit was rushed through the process: it was authored and merged
into -tip of the same day, and pulled in by you just a few days later.
There was no meaningful time for review, testing, or really any sort of
QA.

We really do have a better story now for catching the sort of issues
introduced by these patch: multiple CI systems tripped on this, but
people still need the time to look into it, make sure that the failure
is real and bisect it.

What was the rush in making it skip all of our safeguards? The "bug" has
been there forever, the fix isn't urgent, and no one seemed to care for
quite a while.

Even if this patch was fixing a bug introduced in this merge window, is
the tradeoff around rushing an untested fix worth it vs giving it more
time and shipping it as part of our stable tree?

I'm not trying to pick on this patch in particular - I feel that this is
a systematic issue and should be addressed as part of our process.

--
Thanks,
Sasha

\
 
 \ /
  Last update: 2019-09-08 13:03    [W:0.048 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site