On 5/23/07, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote:
On Tue, 22 May 2007, Ray Lee wrote: > On 5/22/07, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote: > >We don't agree there, as you are not talking about a stable kernel series. > > Ah, so you're planning on submitting these patches for 2.7 then? 2.6 > is perpetually stable. Matt is quite correct; feel free to ask for > clarifications from Linus et al if you need guidance. 2.6.x.y is stable. 2.6.x is not by any reasonably strict definition of stable. Unless you can explain how the stuff that went in 2.6.21 could be added to a stable series kernel, do not even bother replying.
I owe you an apology, I was a bit snippy there. However, to answer your question, they got in by accident and lax testing on the part of the submitters. As someone who has written and maintains a lot of deployed software that gets upgraded live, I feel comfortable in saying that maintaining a perpetually stable software series while allowing new features is entirely possible. The problem is when the maintainers/submitters get the wrong impression, that 2.6.x.y is there to clean up the mess they made. The best of all worlds, in terms of everybody's time spent debugging and fixing, is if the patches are well-tested before submission. If the submitters feel that 2.6.x is an unstable series, then they have no reason to heavily test that code before it goes in. Which is the crux of my problem with your statement. I feel we shouldn't give the wrong idea to those authors. They need to know that the expectation is that 2.6.x is a stable series, and 2.6.x.y is for dealing with unavoidable mistakes.
And for the record, the patches are NOT mine, but since I am the one usually dealing directly with thinkpad firmware, I jumped in to help debug things as a thinkpad firmware was *probably* to blame.
Again, my apologies; I was out of line. Thanks for helping. Ray - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
