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
> >
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
under the:
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
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
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
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
> > >
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"
* 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
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
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
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.
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?
>
>
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
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
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 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 that I
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
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. Right?
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 with 2.6.N
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 other
* 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 sound worked
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 issue
rule.
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.
So just
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
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
is no great
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: send
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 ASAP
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 passes all
the
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
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
* 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
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
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
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
* 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
* 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
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?
>
>
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
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
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
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
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 lines?
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 mainline
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 discussions)
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 Andi on this one.
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?
that's the
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
-
* 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 seems silly.
* 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 people
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 context.
This
- 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 has more
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
never
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
never
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 tested.
- It can
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 are not, into
* 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 principle of keeping
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
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 when
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 correct and
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?
thanks,
greg k-h
---
Everything you ever wanted to know about Linux 2.6 -stable releases.
Rules on
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?
thanks,
greg k-h
---
Everything you ever wanted to know about Linux 2.6 -stable releases.
Rules on
69 matches
Mail list logo
