On Ät 10-03-05 13:25:19, Lee Revell wrote:
> On Thu, 2005-03-10 at 09:31 -0800, Greg KH wrote:
> > On Thu, Mar 10, 2005 at 12:27:23PM -0500, Lee Revell wrote:
> > > On Thu, 2005-03-10 at 08:43 -0800, Greg KH wrote:
> > > > That, and a zillion other specific wordings that people suggested fall
> > >
Chris Friesen <[EMAIL PROTECTED]> writes:
> Neil Brown wrote:
>
>> If a data corruption bug has been there for 10 weeks without being
>> noticed, then the real risk is not that great. We are calling it
>> "-release", not "-hardened".
>
> I disagree. If there's a simple, obvious, small fix that p
Neil Brown wrote:
If a data corruption bug has been there for 10 weeks without being
noticed, then the real risk is not that great. We are calling it
"-release", not "-hardened".
I disagree. If there's a simple, obvious, small fix that passes all the
other criteria, it should go into -stable ASA
On Fri, Mar 11, 2005 at 11:10:37AM +1100, Neil Brown wrote:
> 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."
... Presumably with the obvious exception for security fixes.--b.
-
To unsubscribe from this list:
On Thursday March 10, [EMAIL PROTECTED] wrote:
> On Thu, 2005-03-10 at 21:00 +1100, Neil Brown wrote:
> > One rule that I thought would make sense, but that I don't see listed
> > is:
> >
> > - must fix a regression
> >
> > If some problem was in 2.6.X and is still there in 2.6.X+1, then there
>
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 h
On Thu, 2005-03-10 at 09:43 -0800, Chris Wright wrote:
> * Lee Revell ([EMAIL PROTECTED]) wrote:
> > On Thu, 2005-03-10 at 08:43 -0800, Greg KH wrote:
> > > That, and a zillion other specific wordings that people suggested fall
> > > under the:
> > > or some "oh, that's not good" issue
> > > rule
On Thu, 2005-03-10 at 09:31 -0800, Greg KH wrote:
> On Thu, Mar 10, 2005 at 12:27:23PM -0500, Lee Revell wrote:
> > On Thu, 2005-03-10 at 08:43 -0800, Greg KH wrote:
> > > That, and a zillion other specific wordings that people suggested fall
> > > under the:
> > > or some "oh, that's not good" i
* Lee Revell ([EMAIL PROTECTED]) wrote:
> On Thu, 2005-03-10 at 08:43 -0800, Greg KH wrote:
> > That, and a zillion other specific wordings that people suggested fall
> > under the:
> > or some "oh, that's not good" issue
> > rule.
>
> So just to be 100% clear, no sound with 2.6.N where the so
On Thu, Mar 10, 2005 at 12:27:23PM -0500, Lee Revell wrote:
> On Thu, 2005-03-10 at 08:43 -0800, Greg KH wrote:
> > That, and a zillion other specific wordings that people suggested fall
> > under the:
> > or some "oh, that's not good" issue
> > rule.
>
> So just to be 100% clear, no sound wit
On Thu, 10 Mar 2005, Lee Revell wrote:
>
> So just to be 100% clear, no sound with 2.6.N where the sound worked
> with 2.6.N-1 absolutely does qualify. Right?
If you can send in a patch that fixes it in an obvious way and in less
than 100 lines of context diff, hell yes.
Remember: all the oth
On Thu, 2005-03-10 at 08:43 -0800, Greg KH wrote:
> That, and a zillion other specific wordings that people suggested fall
> under the:
> or some "oh, that's not good" issue
> rule.
So just to be 100% clear, no sound with 2.6.N where the sound worked
with 2.6.N-1 absolutely does qualify. Ri
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?
>
> O
On Thu, 2005-03-10 at 21:00 +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
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:
On Wed, Mar 09, 2005 at 10:34:08AM -0800, Greg KH wrote:
> On Wed, Mar 09, 2005 at 10:56:33AM +0100, Andi Kleen wrote:
> > Greg KH <[EMAIL PROTECTED]> writes:
> > >
> > > Rules on what kind of patches are accepted, and what ones are not, into
> > > the "-stable" tree:
> > > - It must be obviously
http://localhost/blogAndi Kleen wrote:
Greg KH <[EMAIL PROTECTED]> writes:
Rules on what kind of patches are accepted, and what ones are not, into
the "-stable" tree:
- It must be obviously correct and tested.
- It can not bigger than 100 lines, with context.
This rule seems silly. What happens wh
On Wed, Mar 09, 2005 at 08:44:01PM +0100, Andi Kleen wrote:
> But it risks code drift like we had in 2.4 with older kernels
> having more fixes than the newer kernel. And that way lies madness.
I believe it's going to work like this:
* simple fixes are submitted to Linus and -stable, and are app
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> On Wed, Mar 09, 2005 at 10:28:22AM -0800, Chris Wright wrote:
> > * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > > Greg KH <[EMAIL PROTECTED]> writes:
> > > One rule I'm missing:
> > >
> > > - It must be accepted to mainline.
> >
> > This can violate the p
On Wed, Mar 09, 2005 at 08:39:36PM +0100, Andi Kleen wrote:
> On Wed, Mar 09, 2005 at 10:34:08AM -0800, Greg KH wrote:
> > On Wed, Mar 09, 2005 at 10:56:33AM +0100, Andi Kleen wrote:
> > > Greg KH <[EMAIL PROTECTED]> writes:
> > > >
> > > > Rules on what kind of patches are accepted, and what ones
On Wed, Mar 09, 2005 at 10:28:22AM -0800, Chris Wright wrote:
> * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > Greg KH <[EMAIL PROTECTED]> writes:
> > >
> > > Rules on what kind of patches are accepted, and what ones are not, into
> > > the "-stable" tree:
> > > - It must be obviously correct and tes
On Wed, Mar 09, 2005 at 06:00:45PM +, Alan Cox wrote:
> On Mer, 2005-03-09 at 09:56, Andi Kleen wrote:
> > - It must be accepted to mainline.
>
> Strongly disagree. What if the mainline fix is a rewrite of the core API
> involved. Some times you need to put in the short term fix. What must
>
> > - Security patches will be accepted into the -stable tree directly from
> >the security kernel team, and not go through the normal review cycle.
> >Contact the kernel security team for more details on this procedure.
>
> This also sounds like a bad rule. How come the security team ha
On Wed, Mar 09, 2005 at 06:00:45PM +, Alan Cox wrote:
> On Mer, 2005-03-09 at 09:56, Andi Kleen wrote:
> > - It must be accepted to mainline.
>
> Strongly disagree. What if the mainline fix is a rewrite of the core API
> involved. Some times you need to put in the short term fix. What must
>
On Wed, Mar 09, 2005 at 10:56:33AM +0100, Andi Kleen wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> >
> > Rules on what kind of patches are accepted, and what ones are not, into
> > the "-stable" tree:
> > - It must be obviously correct and tested.
> > - It can not bigger than 100 lines, with con
* Alan Cox ([EMAIL PROTECTED]) wrote:
> On Mer, 2005-03-09 at 09:56, Andi Kleen wrote:
> > - It must be accepted to mainline.
>
> Strongly disagree. What if the mainline fix is a rewrite of the core API
> involved. Some times you need to put in the short term fix. What must
> never happen is peop
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> >
> > Rules on what kind of patches are accepted, and what ones are not, into
> > the "-stable" tree:
> > - It must be obviously correct and tested.
> > - It can not bigger than 100 lines, with context.
>
> This rule
On Mer, 2005-03-09 at 09:56, Andi Kleen wrote:
> - It must be accepted to mainline.
Strongly disagree. What if the mainline fix is a rewrite of the core API
involved. Some times you need to put in the short term fix. What must
never happen is people accepting that fix as long term.
How about
-
On Wed, Mar 09, 2005 at 11:24:58AM +0100, Arjan van de Ven wrote:
> On Wed, 2005-03-09 at 10:17 +, Russell King wrote:
> > What about the case (as highlighted in previous discussions) that the
> > stable tree needs a simple "dirty" fix, whereas mainline takes the
> > complex "clean" fix?
>
> t
On Wed, Mar 09, 2005 at 10:17:28AM +, Russell King wrote:
> On Wed, Mar 09, 2005 at 11:10:59AM +0100, Arjan van de Ven wrote:
> > On Wed, 2005-03-09 at 10:56 +0100, Andi Kleen wrote:
> > > One rule I'm missing:
> > >
> > > - It must be accepted to mainline.
> > >
> >
> > I absolutely agree
On Wed, 2005-03-09 at 10:17 +, Russell King wrote:
> On Wed, Mar 09, 2005 at 11:10:59AM +0100, Arjan van de Ven wrote:
> > On Wed, 2005-03-09 at 10:56 +0100, Andi Kleen wrote:
> > > One rule I'm missing:
> > >
> > > - It must be accepted to mainline.
> > >
> >
> > I absolutely agree with An
On Wed, Mar 09, 2005 at 11:10:59AM +0100, Arjan van de Ven wrote:
> On Wed, 2005-03-09 at 10:56 +0100, Andi Kleen wrote:
> > One rule I'm missing:
> >
> > - It must be accepted to mainline.
> >
>
> I absolutely agree with Andi on this one.
What about the case (as highlighted in previous discus
On Wed, 2005-03-09 at 10:56 +0100, Andi Kleen wrote:
> One rule I'm missing:
>
> - It must be accepted to mainline.
>
I absolutely agree with Andi on this one.
> If a mainline patch violates too many of your other rules
> ("Fixes one thing; doesn't do cosmetic changes etc.") perhaps
> the mai
Greg KH <[EMAIL PROTECTED]> writes:
>
> Rules on what kind of patches are accepted, and what ones are not, into
> the "-stable" tree:
> - It must be obviously correct and tested.
> - It can not bigger than 100 lines, with context.
This rule seems silly. What happens when a security fix needs 150
34 matches
Mail list logo
