Re: Let's make a small change to the process

Re: Let's make a small change to the process

[Chuck Ebbert]

On Tue, 26 Oct 2004 at 22:44:21 +0200 Paolo Ciarrocchi wrote:
>
>> 2.6-ac seems to be filling this role right now.
>> 
>
> If the goal of -ac is to only include those fixes, why can't we rename
> it in something more "intuitive" for the final users ?
> Do you see what I mean ?

  AFAICT -ac is not supposed to be a complete collection of bugfixes.

  2.6.9-ac3 was certainly missing a lot of them (haven't seen -ac4 yet.)


--Chuck Ebbert  26-Oct-04  20:33:14

Re: Let's make a small change to the process

[Alan Cox]

On Mer, 2004-10-27 at 03:17, Chuck Ebbert wrote:
> > If the goal of -ac is to only include those fixes, why can't we rename
> > it in something more "intuitive" for the final users ?
> > Do you see what I mean ?
> 
>   AFAICT -ac is not supposed to be a complete collection of bugfixes.
>   2.6.9-ac3 was certainly missing a lot of them (haven't seen -ac4 yet.)

The goal of -ac is to contain the stuff I personally consider important.
A lot of the smaller bugfixes individually are fine but a 'complete set
of bugfixes' turns into a large change set and then needs an entire
validation and release cycle of its own.

Each 2.6.10rc change I merged is on the basis of reward >> risk.

I don't care if its 2.6.9-ac or 2.6.9.4 personally but it's for Linus to
decide if he wants to do that and who he wants to make keeper of the
2.6.x.y tree if anyone.

Alan

Re: Let's make a small change to the process

[Bill Davidsen]

Alan Cox wrote:
> On Mer, 2004-10-27 at 03:17, Chuck Ebbert wrote:
> 
>>>If the goal of -ac is to only include those fixes, why can't we rename
>>>it in something more "intuitive" for the final users ?
>>>Do you see what I mean ?
>>
>>  AFAICT -ac is not supposed to be a complete collection of bugfixes.
>>  2.6.9-ac3 was certainly missing a lot of them (haven't seen -ac4 yet.)
> 
> 
> The goal of -ac is to contain the stuff I personally consider important.
> A lot of the smaller bugfixes individually are fine but a 'complete set
> of bugfixes' turns into a large change set and then needs an entire
> validation and release cycle of its own.
> 
> Each 2.6.10rc change I merged is on the basis of reward >> risk.

Not to give you a swelled head, but at the moment -ac looks more stable 
than anything else widely available.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Let's make a small change to the process

[Chuck Ebbert]

On Wed, 27 Oct 2004 at 16:05 +0100 Alan Cos wrote:

> Each 2.6.10rc change I merged is on the basis of reward >> risk.

  I'm inclined to even accept very small patches that aren't really
bugfixes, like initmem poisoning and the signal delivery patch
that removes unconditional writes to dr7.

  But some of the larger ones scare me, especially when they need
modification to apply cleanly.  Even if the mods are clear, there
can be new logic elsewhere that breaks a backported patch.


--Chuck Ebbert  27-Oct-04  15:49:15

Re: My thoughts on the "new development model"

[Ed Tomlinson]

On Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
> Bill Davidsen wrote:
> 
> > I don't see the need for a development kernel, and it is desirable to be 
> > able to run kernel.org kernels.
> 
>   Problem is, kernel.org 'release' kernels are quite buggy.  For example 2.6.9
> has a long list of bugs:
> 
>   - superio parports don't work
>   - TCP networking using TSO gives memory allocation failures
>   - s390 has a serious security bug (sacf)
>   - ppp hangup is broken with some peers
>   - exec leaks POSIX timer memory and loses signals
>   - auditing can deadlock
>   - O_DIRECT and mmap IO can't be used together
>   - procfs shows the wrong parent PID in some cases
>   - i8042 fails to initialize with some boards using legacy USB
>   - kswapd still goes into a frenzy now and then
> 
>   Sure, the next release will (may?) fix these bugs, but it will definitely
> add a whole set of new ones.

To my mind this just points out the need for a bug fix branch.   e.g. a
branch containing just bug/security fixes against the current stable
kernel.  It might also be worth keeping the branch active for the n-1
stable kernel too.

Ed

PS.  we could call this the Bug/Security or bs kernels.

RE: My thoughts on the "new development model"

[Massimo Cetra]

> On Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
> > Bill Davidsen wrote:
> > 
> > > I don't see the need for a development kernel, and it is 
> desirable 
> > > to be
> > > able to run kernel.org kernels.
> > 
> >   Problem is, kernel.org 'release' kernels are quite buggy.  For 
> > example 2.6.9 has a long list of bugs:
> >
> >   Sure, the next release will (may?) fix these bugs, but it will 
> > definitely add a whole set of new ones.
> 

> To my mind this just points out the need for a bug fix 
> branch.   e.g. a
> branch containing just bug/security fixes against the current 
> stable kernel.  It might also be worth keeping the branch 
> active for the n-1 stable kernel too.

To my mind, we only need to make clear that a stable kernel is a stable
kernel.
Not a kernel for experiments.

To my mind, stock 2.6 kernels are nice for nerds trying patches and
willing to recompile their kernel once a day. They are not suitable for
servers. Several times on testing machines, switching from a 2.6 to the
next one has caused bugs on PCI, acpi, networking and so on.

The direction is lost. How many patchsets for vanilla kernel exist? 

Someone has decided that linux must go on desktops as well and
developing new magnificent features for desktop users is causing serious
problems to the ones who use linux at work on production servers.

2.4 tree is still the best solution for production.
2.6 tree is great for gentoo users who like gcc consuming all CPU
(maxumum respect to gentoo but I prefer debian)

Massimo Cetra

Re: My thoughts on the "new development model"

[Paolo Ciarrocchi]

On Tue, 26 Oct 2004 13:09:59 +0200, Massimo Cetra <mcetra@navynet.it> wrote:
> > On Tuesday 26 October 2004 01:40, Chuck Ebbert wrote:
> > > Bill Davidsen wrote:
> > >
> > > > I don't see the need for a development kernel, and it is
> > desirable
> > > > to be
> > > > able to run kernel.org kernels.
> > >
> > >   Problem is, kernel.org 'release' kernels are quite buggy.  For
> > > example 2.6.9 has a long list of bugs:
> > >
> > >   Sure, the next release will (may?) fix these bugs, but it will
> > > definitely add a whole set of new ones.
> >
> 
> > To my mind this just points out the need for a bug fix
> > branch.   e.g. a
> > branch containing just bug/security fixes against the current
> > stable kernel.  It might also be worth keeping the branch
> > active for the n-1 stable kernel too.
> 
> To my mind, we only need to make clear that a stable kernel is a stable
> kernel.
> Not a kernel for experiments.

2.6 is not an experimental kernel. Not at all.
 
> To my mind, stock 2.6 kernels are nice for nerds trying patches and
> willing to recompile their kernel once a day. They are not suitable for
> servers. Several times on testing machines, switching from a 2.6 to the
> next one has caused bugs on PCI, acpi, networking and so on.

I don't understand what you mean here. 
Did you report these problems to lkml ?
It's the firts time I heard about this kind of problems.
 
> The direction is lost. How many patchsets for vanilla kernel exist?

It was the same for 2.4. And that's not _BAD_, is _GOOD_.
 
> Someone has decided that linux must go on desktops as well and
> developing new magnificent features for desktop users is causing serious
> problems to the ones who use linux at work on production servers.

Who ?
 
> 2.4 tree is still the best solution for production.
> 2.6 tree is great for gentoo users who like gcc consuming all CPU
> (maxumum respect to gentoo but I prefer debian)

I'm sorry, but you sound like a troll...
 
-- 
Paolo

Re: My thoughts on the "new development model"

[Mathieu Segaud]

Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> disait dernièrement que :
 
>> To my mind, we only need to make clear that a stable kernel is a stable
>> kernel.
>> Not a kernel for experiments.
>
> 2.6 is not an experimental kernel. Not at all.

clearly do I agree.
  
>> To my mind, stock 2.6 kernels are nice for nerds trying patches and
>> willing to recompile their kernel once a day. They are not suitable for
>> servers. Several times on testing machines, switching from a 2.6 to the
>> next one has caused bugs on PCI, acpi, networking and so on.
>
> I don't understand what you mean here. 
> Did you report these problems to lkml ?
> It's the firts time I heard about this kind of problems.

I will just add this:
we, young students from all horizons here at the ENS Cachan, run a huge network
(~900 hosts), with 4 important servers, all running 2.6. And my conclusion, as
I cannot speak for my fellow colleagues but think most would agree, is that
these servers behave *a* *lot* *better* since we switch. We had problems first
but they were mostly due to the switch to Debian testing distribution (from
old Woody).
Also we have a 4-way (bi-Xeon with HT) running 2.6.7, playing proxy squid to
serve our entire network, up since 131 days, with no problems; and the 2.6.x
switch was more a blessing than a pain in the butt, since 2.4.x just let him
play more and more in system time.... Thanks to sched domains and _real_ HT
scheduling support.

And these are production servers, no more no less.
  
>> The direction is lost. How many patchsets for vanilla kernel exist?
>
> It was the same for 2.4. And that's not _BAD_, is _GOOD_.

yup -mm, -ac existed in 2.4 series.
and do not forget that -mm series are a stage for patches aiming mainline,
not a special patchset among others.

>> Someone has decided that linux must go on desktops as well and
>> developing new magnificent features for desktop users is causing serious
>> problems to the ones who use linux at work on production servers.
>
> Who ?

Users decided, I guess :)
  
>> 2.4 tree is still the best solution for production.

I do not think so, I think it depends on the hardware you bear.

>> 2.6 tree is great for gentoo users who like gcc consuming all CPU
>> (maxumum respect to gentoo but I prefer debian)

huh ? what's the point ????
Our 2.6 servers run Debian testing with a little trouble.

Best regards, and hurray for Linux 2.6 series !!

Mathieu

-- 
"One of the great things about books is sometimes there are some fantastic
pictures."

George W. Bush
January 3, 2000
Quoted in U.S. News & World Report.

Let's make a small change to the process

[Paolo Ciarrocchi]

Hi all,
despite I know you are all bored with the " I know how to improve the
process" email but I want to share with you this idea .-)

Both Andrew and Linus are doing an impressive job so I really don't
think we need to change the way they are working.

What I'm suggesting is start offering 2.6.X:Y kernel, you did for 2.6.8.1 so...

The .Y patchset contains only important security fix (all stuff you
think are important) and is weekly uploaded to kernel.org

Doing that, people:
-  can stop running "personal version of vanilla kernel
-  don't need to wait till next Linus' release in order to have a
security bug fixed

We, of course, need a maintainer for it,
maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
for a long time), maybe Alan (that is already applying these kind of
fixes to his tree), maybe someone else... ?

Sounds reasonable ?

-- 
Paolo

Re: Let's make a small change to the process

[William Lee Irwin III]

On Tue, Oct 26, 2004 at 10:16:08PM +0200, Paolo Ciarrocchi wrote:
> despite I know you are all bored with the " I know how to improve the
> process" email but I want to share with you this idea .-)
> Both Andrew and Linus are doing an impressive job so I really don't
> think we need to change the way they are working.
> What I'm suggesting is start offering 2.6.X:Y kernel, you did for
> 2.6.8.1 so...
> The .Y patchset contains only important security fix (all stuff you
> think are important) and is weekly uploaded to kernel.org
> Doing that, people:
> -  can stop running "personal version of vanilla kernel
> -  don't need to wait till next Linus' release in order to have a
> security bug fixed
> We, of course, need a maintainer for it,
> maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
> for a long time), maybe Alan (that is already applying these kind of
> fixes to his tree), maybe someone else... ?
> Sounds reasonable ?

Not normally the first thing I'd volunteer for. I probably won't at
all unless demand comes down from on high.

-- wli

Re: Let's make a small change to the process

[Paolo Ciarrocchi]

On Tue, 26 Oct 2004 13:22:24 -0700, William Lee Irwin III
<wli@holomorphy.com> wrote:
> On Tue, Oct 26, 2004 at 10:16:08PM +0200, Paolo Ciarrocchi wrote:
> 
> 
> > despite I know you are all bored with the " I know how to improve the
> > process" email but I want to share with you this idea .-)
> > Both Andrew and Linus are doing an impressive job so I really don't
> > think we need to change the way they are working.
> > What I'm suggesting is start offering 2.6.X:Y kernel, you did for
> > 2.6.8.1 so...
> > The .Y patchset contains only important security fix (all stuff you
> > think are important) and is weekly uploaded to kernel.org
> > Doing that, people:
> > -  can stop running "personal version of vanilla kernel
> > -  don't need to wait till next Linus' release in order to have a
> > security bug fixed
> > We, of course, need a maintainer for it,
> > maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
> > for a long time), maybe Alan (that is already applying these kind of
> > fixes to his tree), maybe someone else... ?
> > Sounds reasonable ?
> 
> Not normally the first thing I'd volunteer for. I probably won't at
> all unless demand comes down from on high.

Well, I wrote your name because you are a great developer but I
understand you prefer doing something else ;)

What about just the *idea* ?

-- 
Paolo

Re: Let's make a small change to the process

[William Lee Irwin III]

On Tue, 26 Oct 2004 13:22:24 -0700, William Lee Irwin III wrote:
>> Not normally the first thing I'd volunteer for. I probably won't at
>> all unless demand comes down from on high.

On Tue, Oct 26, 2004 at 10:26:40PM +0200, Paolo Ciarrocchi wrote:
> Well, I wrote your name because you are a great developer but I
> understand you prefer doing something else ;)
> What about just the *idea* ?

The idea is fine.


-- wli

Re: Let's make a small change to the process

[Dave Jones]

On Tue, Oct 26, 2004 at 10:16:08PM +0200, Paolo Ciarrocchi wrote:
 
 > The .Y patchset contains only important security fix (all stuff you
 > think are important) and is weekly uploaded to kernel.org
 > 
 > Doing that, people:
 > -  can stop running "personal version of vanilla kernel
 > -  don't need to wait till next Linus' release in order to have a
 > security bug fixed
 > 
 > We, of course, need a maintainer for it,
 > maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
 > for a long time), maybe Alan (that is already applying these kind of
 > fixes to his tree), maybe someone else... ?

2.6-ac seems to be filling this role right now.

		Dave

Re: Let's make a small change to the process

[Paolo Ciarrocchi]

On Tue, 26 Oct 2004 16:36:44 -0400, Dave Jones <davej@redhat.com> wrote:
> On Tue, Oct 26, 2004 at 10:16:08PM +0200, Paolo Ciarrocchi wrote:
> 
> > The .Y patchset contains only important security fix (all stuff you
> > think are important) and is weekly uploaded to kernel.org
> >
> > Doing that, people:
> > -  can stop running "personal version of vanilla kernel
> > -  don't need to wait till next Linus' release in order to have a
> > security bug fixed
> >
> > We, of course, need a maintainer for it,
> > maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
> > for a long time), maybe Alan (that is already applying these kind of
> > fixes to his tree), maybe someone else... ?
> 
> 2.6-ac seems to be filling this role right now.
> 

Correct.
But as I user I tend to look at kernel.org and download "The latest
stable version of the Linux kernel is".

If the goal of -ac is to only include those fixes, why can't we rename
it in something more "intuitive" for the final users ?
Do you see what I mean ?


-- 
Paolo

Re: Let's make a small change to the process

[Jan Knutar]

On Tuesday 26 October 2004 23:44, Paolo Ciarrocchi wrote:

> If the goal of -ac is to only include those fixes, why can't we rename
> it in something more "intuitive" for the final users ?
> Do you see what I mean ?

"Final users" are those like me, who so far are quite satisfied[1] with the
distribution kernel. Advanced users will be aware of the existence of
other than kernel.org versions of the kernel, and will hopefully be able
to pick one suited to their particular fuzzy feelings. 

During 2.4 development (IIRC) it was somewhat fairly generic knowledge
amongst those who had progressed marginally beyond booting linux, to
compiling some kernel from sources, what -ac postfix meant. Why that
sort of community knowledge osmosis wouldn't be possible or active today
also, I do not know. Perhaps people are just in general afraid of change.


[1] As in, the Fedora Core 2 kernel did not immediately give me such awful
performance that it made me get a kernel.org kernel to get back the magnitude
or so performance loss of the typical Redhat9 kernel. Benchmarks purely
subjective of course, sorry. :-/

Re: Let's make a small change to the process

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Paolo Ciarrocchi wrote:
| Hi all,
| despite I know you are all bored with the " I know how to improve the
| process" email but I want to share with you this idea .-)
|
| Both Andrew and Linus are doing an impressive job so I really don't
| think we need to change the way they are working.
|
| What I'm suggesting is start offering 2.6.X:Y kernel, you did for
2.6.8.1 so...
|
| The .Y patchset contains only important security fix (all stuff you
| think are important) and is weekly uploaded to kernel.org
|

Eww.

2.6.10 got an -rc about 4 days after 2.6.9 went stable.  This would be a
bit too rapid for my tastes; I don't like ideas that potentially load
maintainers.

[...]

| We, of course, need a maintainer for it,

Yes, a little too much to maintain though isn't it?  Maintainers to
continuously upkeep revisions that come out every few weeks potentially?
~ Remember it's got to be able to withstand the test of time for quite a
while; why are people still maintaining 2.2?

| maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
| for a long time), maybe Alan (that is already applying these kind of
| fixes to his tree), maybe someone else... ?
|

Common courteousy, don't volunteer people.  :)

| Sounds reasonable ?
|

Sounds too fast.  I don't predict having a maintainer for each minor
release of the kernel (which is what you're saying here essentially), so
there'd be a need for one or a handfull of maintainers to spend loads of
time backporting fixes to a quickly mounting set of kernels.

I had <shameless plug> suggested an hour or two ago a scheme where the
current development model be based off, but periodic releases be made
"stable," basing on approximately 6 months between releases </shameless
plug>.  I think it's a bit more sane to say that a maintainer may mount
up 4 kernels in 2 years to backport bugfixes into, if nobody else steps
up to the plate to help.

Of course, eventually official support has to be dropped in either
scheme, because the same problem is faced:  We can't expect people to
maintain a continuously mounting number of kernel revisions once the
workload becomes sufficiently high.  A balance must be made between
dropping support for a non-volitile code base, and maintaining a support
period sufficiently long.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBfrg7hDd4aOud5P8RAo5eAJ4/lbCRuNfVM9iNoNaEOBX5wdqTlwCfWUK7
XM9z2dgXmkMWg28xZzlWeMI=
=edrQ
-----END PGP SIGNATURE-----

Re: Let's make a small change to the process

[Paolo Ciarrocchi]

On Tue, 26 Oct 2004 16:48:59 -0400, John Richard Moser
<nigelenki@comcast.net> wrote:
[...]
> 
> | We, of course, need a maintainer for it,
> 
> Yes, a little too much to maintain though isn't it?  Maintainers to
> continuously upkeep revisions that come out every few weeks potentially?
> ~ Remember it's got to be able to withstand the test of time for quite a
> while; why are people still maintaining 2.2?
> 
> | maybe someone from OSDL (Randy?), maybe wli (he maintained his tree
> | for a long time), maybe Alan (that is already applying these kind of
> | fixes to his tree), maybe someone else... ?
> |
> 
> Common courteousy, don't volunteer people.  :)

Just wrote name a few "famous" and "great" kernel hackers :)
 
> | Sounds reasonable ?
> |
> 
> Sounds too fast.  I don't predict having a maintainer for each minor
> release of the kernel (which is what you're saying here essentially), so
> there'd be a need for one or a handfull of maintainers to spend loads of
> time backporting fixes to a quickly mounting set of kernels.

Yes, one maintainer.
But I'm not sure that each minor release of ther kernel needs a .Y version.
 
> I had <shameless plug> suggested an hour or two ago a scheme where the
> current development model be based off, but periodic releases be made
> "stable," basing on approximately 6 months between releases </shameless
> plug>.  I think it's a bit more sane to say that a maintainer may mount
> up 4 kernels in 2 years to backport bugfixes into, if nobody else steps
> up to the plate to help.
> 
> Of course, eventually official support has to be dropped in either
> scheme, because the same problem is faced:  We can't expect people to
> maintain a continuously mounting number of kernel revisions once the
> workload becomes sufficiently high.  A balance must be made between
> dropping support for a non-volitile code base, and maintaining a support
> period sufficiently long.

Not sure I get your point.
Again,
-ac is almost what I'm suggesting but I'd prefer to change it's name
and formalize it publishing the .Y patchset to kernel,org with a name
useful for the users.

Time to sleep now,
I'll flight to Germany tomorrow so I'll be offline till Tuesday. 
But hey, you don't need me anymore ;-)

-- 
Paolo