Re: [PATCH] x86/pci: don't use crs for root if we only have oneroot bus

[Ingo Molnar]

* Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/