Messages in this thread | | | Date | Sun, 8 Sep 2019 07:02:53 -0400 | From | Sasha Levin <> | Subject | Re: 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
| |