* 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-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
