Re: [RFC] -stable, how it's going to work.

[Neil Brown]

On Thursday March 10, greg@xxxxxxxxx wrote:
> On Thu, Mar 10, 2005 at 09:00:51PM +1100, Neil Brown wrote:
> > On Tuesday March 8, greg@xxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/