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

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: 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

[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

[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

[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

[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

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: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

[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

[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

[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, 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

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