lkml.org 
[lkml]   [2009]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86/pci: don't use crs for root if we only have one root bus

* Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> > [ There's a difference between "we're supposed to find and fix bugs
> > in the -rc series", and "I release known-buggy -rc1's since we're
> > supposed to fix it later". For similar reasons, I hate pulling
> > known-buggy stuff during the merge window - it's ok if it shows
> > itself to be buggy _later_, but if people send me stuff that they
> > know is buggy as they send it to me, then that's a problem. ]
>
> Yeah, 100% agreed. I didn't hear any reports until after people
> started using your tree, so I think this case was handled
> correctly: push something that *seems* ok upstream, but with eyes
> wide open for the possibility we'd need to revert.

There's only one small gripe i have with the handling of it: the
timing. "9e9f46c: PCI: use ACPI _CRS data by default" was written
and committed on June 11th, two days _after_ the merge window
opened.

That's way too late for maybe-broken changes to x86 lowlevel details
(especially if it touches hw-environmental interaction - which is
very hard to test with meaningful coverage), and it's also pretty
much the worst moment to solicit testing from people who are busy
getting their stuff to Linus and who are busy testing out any of the
unexpected interactions and bugs.

So this was, to a certain degree, a predictable outcome. Trees in
the Linux "critical path" of testing (core kernel, x86, core
networking, very common drivers, PCI, driver core, VFS, etc.) should
generally try to cool down 1-2 weeks before the merge window -
because breakage there can do a lot of knock-on cascading damage.
Two weeks is not a lot of time and the effects of showstopper bugs
get magnified disproportionately.

Ingo


\
 
 \ /
  Last update: 2009-06-25 09:07    [W:0.944 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site