On Thursday March 10, [EMAIL PROTECTED] wrote: > On Thu, Mar 10, 2005 at 09:00:51PM +1100, Neil Brown wrote: > > On Tuesday March 8, [EMAIL PROTECTED] wrote: > > > So here's a first cut at how this 2.6 -stable release process is going > > > to work that Chris and I have come up with. Does anyone have any > > > problems/issues/questions with this? > > > > One rule that I thought would make sense, but that I don't see listed > > is: > > > > - must fix a regression > > That, and a zillion other specific wordings that people suggested fall > under the: > or some "oh, that's not good" issue > rule. > > I didn't feel like being all lawyer-like and explicitly spelling out all > of the different kinds of bugs that we would be accepting patches for :) > > So yes, I don't have a problem with patches to fix regressions.
I think you did not get the meaning that I was trying to convey... I didn't mean "If it fixes a regression, it should be accepted." I meant "If it does not fix a regression, it should not be accepted." I have the impression that the 2.6.x.y series were suggested because of regressions in 2.6.11 over 2.6.10 and we needed a way to respond to that. I think it should purely be a response to that. The issue that made me think through this is the locking bug in nfs (there is a significant delay in getting a contended lock after the holder drops it). It has been suggested at least twice for 2.6.11.y. While it would be nice to have it fixed, I really don't think it should be a candidate for 2.6.11.y. It should go into 2.6.12 (which it will) and that should be released 6-10 weeks post 2.6.11 which, given the bug as been around for a lot longer than that without being widely noticed, should be soon enough. I fear that if too many bug fixes go into 2.6.11.y, it might seem to take the pressure of 2.6.12 coming out in a timely fashion, and I wouldn't like to see that. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
