Release Policy [was: Linux 2.4.16 ]

Release Policy [was: Linux 2.4.16 ]

[David Relson]

Marcelo,

Thank you for stepping forward to be the maintainer of the 2.4 tree.  This 
is a very valuable and important service for use Linux users.

Also, thank you for releasing 2.4.16.  I have it building on my linux box 
as I write this message :-)

Over the last few days, there have been lots of messages regarding "Kernel 
Release" and "-preX vs. -rcX".  You, as the official maintainer of kernel 
2.4 are the person who actually creates the release policy and makes it happen.

Would you care to share your thoughts on this matter?

David

At 07:30 AM 11/26/01, Marcelo Tosatti wrote:

>Hi,
>
>Due to the corruption problems on 2.4.15, I'm releasing 2.4.16.

Re: Release Policy [was: Linux 2.4.16 ]

[Marcelo Tosatti]

On Mon, 26 Nov 2001, David Relson wrote:

> Marcelo,
> 
> Thank you for stepping forward to be the maintainer of the 2.4 tree.  This 
> is a very valuable and important service for use Linux users.
> 
> Also, thank you for releasing 2.4.16.  I have it building on my linux box 
> as I write this message :-)
> 
> Over the last few days, there have been lots of messages regarding "Kernel 
> Release" and "-preX vs. -rcX".  You, as the official maintainer of kernel 
> 2.4 are the person who actually creates the release policy and makes it happen.
> 
> Would you care to share your thoughts on this matter?

Sorry for not being able to discuss this issues... Its just that I'm too
busy doing the maintenance and other stuff at Conectiva at the same time
(people are flooding me with patches, btw, please stop for a while).

Daniel Quinlan suggested me to release a "pre-final" release before the
real final one (which would catch most "stupid" bugs), and I think thats a
nice way of solving the problem.

I'll _probably_ do that --- not sure yet, though. 

Re: Release Policy [was: Linux 2.4.16 ]

[David Relson]

At 12:22 PM 11/26/01, Chris Meadors wrote:

>Aren't all the -pre's pre-finals?  And what if there is a big bug found in
>the -final, it will obviously be followed up with a -final-final?
>
>I like the ISC's release methods.  The do -rc's (-pre's would be fine for
>the kernel as it is already established), each -rc fixes problems found
>with the previous.  When an -rc has been out long enough with no more bug
>reports they release that code, WITHOUT changes.
>
>-Chris

Chris,

I think of -pre releases as beta code - testable and likely broken.  An -rc 
release would be "possibly broken".  If problems are encountered, fix ONLY 
those problems to generate the next -rc.  If it's O.K., then make it "final".

David

Re: Release Policy [was: Linux 2.4.16 ]

[Bill Davidsen]

On Mon, 26 Nov 2001, David Relson wrote:

> At 12:22 PM 11/26/01, Chris Meadors wrote:
> 
> >Aren't all the -pre's pre-finals?  And what if there is a big bug found in
> >the -final, it will obviously be followed up with a -final-final?

All the -pre's are before the final, but not release candidates. I think
the rc until recently has been the one where someone said "we've put a
hell of a lot of new stuff in this..." and concentrated on reported bugs,
if any.

> >I like the ISC's release methods.  The do -rc's (-pre's would be fine for
> >the kernel as it is already established), each -rc fixes problems found
> >with the previous.  When an -rc has been out long enough with no more bug
> >reports they release that code, WITHOUT changes.
 
> I think of -pre releases as beta code - testable and likely broken.  An -rc 
> release would be "possibly broken".  If problems are encountered, fix ONLY 
> those problems to generate the next -rc.  If it's O.K., then make it "final".

Other than some quibbling about nomenclature, that's how I see it. We
always had an alpha version for in-house testing only, then a beta for
selected users, which for Linux would be those who have the guts to run
the downloads, and then a release.

I did commenrcial software development for a few decades and that was
usually the practice, and that's what people like Microsoft were doing
when I did a few beta tests for them. I think it's a good model for Linux
stable kernel series.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Release Policy [was: Linux 2.4.16 ]

[Chris Meadors]

On Mon, 26 Nov 2001, Marcelo Tosatti wrote:

> Sorry for not being able to discuss this issues... Its just that I'm too
> busy doing the maintenance and other stuff at Conectiva at the same time
> (people are flooding me with patches, btw, please stop for a while).
>
> Daniel Quinlan suggested me to release a "pre-final" release before the
> real final one (which would catch most "stupid" bugs), and I think thats a
> nice way of solving the problem.
>
> I'll _probably_ do that --- not sure yet, though.

Aren't all the -pre's pre-finals?  And what if there is a big bug found in
the -final, it will obviously be followed up with a -final-final?

I like the ISC's release methods.  The do -rc's (-pre's would be fine for
the kernel as it is already established), each -rc fixes problems found
with the previous.  When an -rc has been out long enough with no more bug
reports they release that code, WITHOUT changes.

-Chris
-- 
Two penguins were walking on an iceberg.  The first penguin said to the
second, "you look like you are wearing a tuxedo."  The second penguin
said, "I might be..."                         --David Lynch, Twin Peaks

Re: Release Policy [was: Linux 2.4.16 ]

[Marcelo Tosatti]

On Mon, 26 Nov 2001, Chris Meadors wrote:

> On Mon, 26 Nov 2001, Marcelo Tosatti wrote:
> 
> > Sorry for not being able to discuss this issues... Its just that I'm too
> > busy doing the maintenance and other stuff at Conectiva at the same time
> > (people are flooding me with patches, btw, please stop for a while).
> >
> > Daniel Quinlan suggested me to release a "pre-final" release before the
> > real final one (which would catch most "stupid" bugs), and I think thats a
> > nice way of solving the problem.
> >
> > I'll _probably_ do that --- not sure yet, though.
> 
> Aren't all the -pre's pre-finals? 

No. Just the -pre-final is a -pre-final. :) 

-pre-final basically means that this is the "candidate" release for the
final.

I could call it "candidate" or whatever (I don't really care about the
name).

> And what if there is a big bug found in the -final, it will obviously
> be followed up with a -final-final?

If people don't like the -pre-final name, I can call it "-candidate" as I
said previously.

> I like the ISC's release methods.  The do -rc's (-pre's would be fine
> for the kernel as it is already established), each -rc fixes problems
> found with the previous.  When an -rc has been out long enough with no
> more bug reports they release that code, WITHOUT changes.

Thats exactly the idea with the "pre-final" thingie. 

Re: Release Policy [was: Linux 2.4.16 ]

[David Rees]

On Mon, Nov 26, 2001 at 01:54:11PM -0200, Marcelo Tosatti wrote:
> 
> > I like the ISC's release methods.  The do -rc's (-pre's would be fine
> > for the kernel as it is already established), each -rc fixes problems
> > found with the previous.  When an -rc has been out long enough with no
> > more bug reports they release that code, WITHOUT changes.
> 
> Thats exactly the idea with the "pre-final" thingie. 

Most groups use -rc release candidate releases, so using that instead of
-pre-final would lead to the least confusion.

A 2.4.17 release might look like this:

Release 2.4.17-preX until all the new stuff you want is in.
Release 2.4.17-rcX until no-one complains about the new stuff.
Release the last 2.4.17-rcX as 2.4.17 and hope no one finds anything
embarassing (which will probably happen anyway.

Seems to me though, that you can simply put a note in your Changelog which
-pre releases are bound to be to the next final revision, this will save us
from yet another numbering scheme.

-Dave

Re: Release Policy [was: Linux 2.4.16 ]

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.21.0111261351160.13786-100000@freak.distro.conectiva>
By author:    Marcelo Tosatti <marcelo@conectiva.com.br>
In newsgroup: linux.dev.kernel
> 
> No. Just the -pre-final is a -pre-final. :) 
> 
> -pre-final basically means that this is the "candidate" release for the
> final.
> 
> I could call it "candidate" or whatever (I don't really care about the
> name).
> 

That's what a release candidate is.  Expect the possibility that you
might have more than one release candidate.

The -rc scheme proposed seems very clean indeed.

Oh, and yes, if you settle on a naming scheme, *please* let me know
ahead of time so I can update the scripts to track it, rather than
finding out by having hundreds of complaints in my mailbox...

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Release Policy [was: Linux 2.4.16 ]

[David Weinehall]

On Mon, Nov 26, 2001 at 10:12:50AM -0800, H. Peter Anvin wrote:
> Followup to:  <Pine.LNX.4.21.0111261351160.13786-100000@freak.distro.conectiva>
> By author:    Marcelo Tosatti <marcelo@conectiva.com.br>
> In newsgroup: linux.dev.kernel
> > 
> > No. Just the -pre-final is a -pre-final. :) 
> > 
> > -pre-final basically means that this is the "candidate" release for the
> > final.
> > 
> > I could call it "candidate" or whatever (I don't really care about the
> > name).
> > 
> 
> That's what a release candidate is.  Expect the possibility that you
> might have more than one release candidate.
> 
> The -rc scheme proposed seems very clean indeed.
> 
> Oh, and yes, if you settle on a naming scheme, *please* let me know
> ahead of time so I can update the scripts to track it, rather than
> finding out by having hundreds of complaints in my mailbox...

I for one used the -pre and -pre-final naming for the v2.0.39-series,
and I'll probably use the same naming for the final pre-patch of
v2.0.40, _unless_ there's some sort of agreement on another naming 
scheme. I'd be perfectly content with using the -rc naming for the
final instead. The important thing is not the naming itself, but
consistency between the different kernel-trees.


Regards: David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Release Policy [was: Linux 2.4.16 ]

[H. Peter Anvin]

David Weinehall wrote:

>>
>>Oh, and yes, if you settle on a naming scheme, *please* let me know
>>ahead of time so I can update the scripts to track it, rather than
>>finding out by having hundreds of complaints in my mailbox...
>>
> 
> I for one used the -pre and -pre-final naming for the v2.0.39-series,
> and I'll probably use the same naming for the final pre-patch of
> v2.0.40, _unless_ there's some sort of agreement on another naming 
> scheme. I'd be perfectly content with using the -rc naming for the
> final instead. The important thing is not the naming itself, but
> consistency between the different kernel-trees.
> 


Consistency is a Very Good Thing[TM] (says the one who tries to teach
scripts to understand the naming.)  The advantage with the -rc naming is
that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
-pre-final-really-i-mean-it-this-time phenomenon when the release
candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3.  There is no
shame in needing more than one release candidate.

	-hpa

Re: Release Policy [was: Linux 2.4.16 ]

[Marcelo Tosatti]

On Mon, 26 Nov 2001, H. Peter Anvin wrote:

> David Weinehall wrote:
> 
> >>
> >>Oh, and yes, if you settle on a naming scheme, *please* let me know
> >>ahead of time so I can update the scripts to track it, rather than
> >>finding out by having hundreds of complaints in my mailbox...
> >>
> > 
> > I for one used the -pre and -pre-final naming for the v2.0.39-series,
> > and I'll probably use the same naming for the final pre-patch of
> > v2.0.40, _unless_ there's some sort of agreement on another naming 
> > scheme. I'd be perfectly content with using the -rc naming for the
> > final instead. The important thing is not the naming itself, but
> > consistency between the different kernel-trees.
> > 
> 
> 
> Consistency is a Very Good Thing[TM] (says the one who tries to teach
> scripts to understand the naming.)  The advantage with the -rc naming is
> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
> -pre-final-really-i-mean-it-this-time phenomenon when the release
> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3.  There is no
> shame in needing more than one release candidate.

Agreed. I stick with the -rc naming convention for 2.4+... 

Re: Release Policy [was: Linux 2.4.16 ]

[H. Peter Anvin]

Marcelo Tosatti wrote:

>>
>>Consistency is a Very Good Thing[TM] (says the one who tries to teach
>>scripts to understand the naming.)  The advantage with the -rc naming is
>>that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
>>-pre-final-really-i-mean-it-this-time phenomenon when the release
>>candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3.  There is no
>>shame in needing more than one release candidate.
>>
> 
> Agreed. I stick with the -rc naming convention for 2.4+... 
> 

I have updated the kernel.org scripts to recognize the -rc naming
convention.  Any -rc patch found is assumed to be newer than any -pre
patch found.

I will try to add tracking of the v2.0 and v2.2 trees sometime later this
week.

	-hpa

Re: Release Policy [was: Linux 2.4.16 ]

[François Cami]

Marcelo Tosatti wrote:


> Agreed. I stick with the -rc naming convention for 2.4+... 


Thanks a lot - much better that way.

François

Re: Release Policy [was: Linux 2.4.16 ]

[Jonathan Lundell]

At 3:25 PM -0200 11/26/01, Marcelo Tosatti wrote:
>  > Consistency is a Very Good Thing[TM] (says the one who tries to teach
>>  scripts to understand the naming.)  The advantage with the -rc naming is
>>  that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
>>  -pre-final-really-i-mean-it-this-time phenomenon when the release
>>  candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3.  There is no
>>  shame in needing more than one release candidate.
>
>Agreed. I stick with the -rc naming convention for 2.4+...

A quibble: "release" seems an odd word to choose for a Linux kernel. 
Since we're calling the target kernel "final", how about -fc1, 
-fc2...?
-- 
/Jonathan Lundell.

Re: Release Policy [was: Linux 2.4.16 ]

[Flavio Stanchina]

On Monday 26 November 2001 20:06, Jonathan Lundell wrote:

> >Agreed. I stick with the -rc naming convention for 2.4+...
> A quibble: "release" seems an odd word to choose for a Linux kernel.
> Since we're calling the target kernel "final", how about -fc1,
> -fc2...?

Sounds a bit too much like the f-word.

"rc" is the universally recognized name for such things (heck, even 
Microsoft) so I'd stick with it.

-- 
Ciao,
    Flavio Stanchina
    Trento - Italy

"The best defense against logic is ignorance."
http://spazioweb.inwind.it/fstanchina/

Re: Release Policy [was: Linux 2.4.16 ]

[Jonathan Lundell]

At 8:28 PM +0100 11/26/01, Flavio Stanchina wrote:
>On Monday 26 November 2001 20:06, Jonathan Lundell wrote:
>
>>  >Agreed. I stick with the -rc naming convention for 2.4+...
>>  A quibble: "release" seems an odd word to choose for a Linux kernel.
>>  Since we're calling the target kernel "final", how about -fc1,
>>  -fc2...?
>
>Sounds a bit too much like the f-word.
>
>"rc" is the universally recognized name for such things (heck, even
>Microsoft) so I'd stick with it.

So in a choice between sex, love and Microsoft, we choose Microsoft?

I'm more used to -fc, myself; in fact I was unfamiliar with -rc. But 
if Microsoft uses -rc, by all means, let's follow suit. ;-)
-- 
/Jonathan Lundell.

Re: Release Policy [was: Linux 2.4.16 ]

[David Weinehall]

On Mon, Nov 26, 2001 at 03:25:24PM -0200, Marcelo Tosatti wrote:
> 
> 
> On Mon, 26 Nov 2001, H. Peter Anvin wrote:
> 
> > David Weinehall wrote:
> > 
> > >>
> > >>Oh, and yes, if you settle on a naming scheme, *please* let me know
> > >>ahead of time so I can update the scripts to track it, rather than
> > >>finding out by having hundreds of complaints in my mailbox...
> > >>
> > > 
> > > I for one used the -pre and -pre-final naming for the v2.0.39-series,
> > > and I'll probably use the same naming for the final pre-patch of
> > > v2.0.40, _unless_ there's some sort of agreement on another naming 
> > > scheme. I'd be perfectly content with using the -rc naming for the
> > > final instead. The important thing is not the naming itself, but
> > > consistency between the different kernel-trees.
> > > 
> > 
> > 
> > Consistency is a Very Good Thing[TM] (says the one who tries to teach
> > scripts to understand the naming.)  The advantage with the -rc naming is
> > that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
> > -pre-final-really-i-mean-it-this-time phenomenon when the release
> > candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3.  There is no
> > shame in needing more than one release candidate.
> 
> Agreed. I stick with the -rc naming convention for 2.4+... 

Ok, then I'll do likewise.

Linus, Alan?


Regards: David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Release Policy [was: Linux 2.4.16 ]

[junio]

>>>>> "MT" == Marcelo Tosatti <marcelo@conectiva.com.br> writes:

MT> On Mon, 26 Nov 2001, H. Peter Anvin wrote:
>> Consistency is a Very Good Thing[TM] (says the one who tries to teach
>> scripts to understand the naming.)  The advantage with the -rc naming is
>> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
>> -pre-final-really-i-mean-it-this-time phenomenon when the release
>> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3.  There is no
>> shame in needing more than one release candidate.

MT> Agreed. I stick with the -rc naming convention for 2.4+... 

(This is a request to maintainers of three stable trees).

While we are on the topic, could you also coordinate to keep the
EXTRAVERSION strings consistent?  2.4.X-preN uses "-preN" but
2.2.X-preN uses "preN" without leading "-".

Re: Release Policy [was: Linux 2.4.16 ]

[David Weinehall]

On Mon, Nov 26, 2001 at 12:39:34PM -0800, junio@siamese.dhis.twinsun.com wrote:
> >>>>> "MT" == Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> 
> MT> On Mon, 26 Nov 2001, H. Peter Anvin wrote:
> >> Consistency is a Very Good Thing[TM] (says the one who tries to teach
> >> scripts to understand the naming.)  The advantage with the -rc naming is
> >> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
> >> -pre-final-really-i-mean-it-this-time phenomenon when the release
> >> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3.  There is no
> >> shame in needing more than one release candidate.
> 
> MT> Agreed. I stick with the -rc naming convention for 2.4+... 
> 
> (This is a request to maintainers of three stable trees).
> 
> While we are on the topic, could you also coordinate to keep the
> EXTRAVERSION strings consistent?  2.4.X-preN uses "-preN" but
> 2.2.X-preN uses "preN" without leading "-".

I'm using "-preN" with a leading "-", and will probably continue
doing so.


Regards: David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Release Policy [was: Linux 2.4.16 ]

[H. Peter Anvin]

David Weinehall wrote:

>>
>>While we are on the topic, could you also coordinate to keep the
>>EXTRAVERSION strings consistent?  2.4.X-preN uses "-preN" but
>>2.2.X-preN uses "preN" without leading "-".
>>
> 
> I'm using "-preN" with a leading "-", and will probably continue
> doing so.
> 


This matches the filename convention, and seems to be what most users expect.

	-hpa

Re: Release Policy [was: Linux 2.4.16 ]

[Gregory Maxwell]

On Mon, Nov 26, 2001 at 10:31:41AM -0800, H. Peter Anvin wrote:
> Consistency is a Very Good Thing[TM] (says the one who tries to teach
> scripts to understand the naming.)  The advantage with the -rc naming is
> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
> -pre-final-really-i-mean-it-this-time phenomenon when the release
> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3.  There is no
> shame in needing more than one release candidate.

Why not just disguard this sillyness of alphabetic characters in version
numbers... Just carry through the same structure used by major/minor:
I.e.

2.0.39 < released 2.0.39
2.0.39.1.1 < first development snapshot of the kernel which will eventually
	     be 2.0.40
2.0.39.1.2 < second
2.0.39.1.n < Nth
2.0.39.2.1 < first RC
2.0.39.2.2 < second RC
2.0.39.3.1 < opps! Development went too long and we had to break feature
	     freeze to add important features.
2.0.39.4.1 < Trying to stablize again
2.0.39.4.2 < a few more bugs fixxed
2.0.40	   < Looks like 2.0.39.4.2 got it right!

Re: Release Policy [was: Linux 2.4.16 ]

[Svein Erik Brostigen]

Gregory Maxwell wrote:

>On Mon, Nov 26, 2001 at 10:31:41AM -0800, H. Peter Anvin wrote:
>
>>Consistency is a Very Good Thing[TM] (says the one who tries to teach
>>scripts to understand the naming.)  The advantage with the -rc naming is
>>that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
>>-pre-final-really-i-mean-it-this-time phenomenon when the release
>>candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3.  There is no
>>shame in needing more than one release candidate.
>>
>
>Why not just disguard this sillyness of alphabetic characters in version
>numbers... Just carry through the same structure used by major/minor:
>I.e.
>
>2.0.39 < released 2.0.39
>2.0.39.1.1 < first development snapshot of the kernel which will eventually
>	     be 2.0.40
>2.0.39.1.2 < second
>2.0.39.1.n < Nth
>2.0.39.2.1 < first RC
>2.0.39.2.2 < second RC
>2.0.39.3.1 < opps! Development went too long and we had to break feature
>	     freeze to add important features.
>2.0.39.4.1 < Trying to stablize again
>2.0.39.4.2 < a few more bugs fixxed
>2.0.40	   < Looks like 2.0.39.4.2 got it right!
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
What really scares me is not so much the way the kernels are numbered as 
the way features gets added to
the kernels.
Internally in Oracle we do not add new features to a release number, 
just bug-fixes.
Hence 2.4.0 is the base release of the 2.4.x kernel series. the minor 
x-number should just indicate a bug-fix
release. Thus, no new features should get added to the 2.4 kernel with 
this numbering schema.
If you really want to add features into the 2.4.x kernel, you also need 
to extend the numbering schema.
I.e 2.4.0.x wil then be the bug-fix releases and  2.4.1.x will have new 
features.
This makes it easier to maintain and to understand what is happening 
between the various releases.

As far as I can understand, today, new features are added to a released 
kernel without any sensible numbering scheme
identifying this fact. I don't know if a 2.4.10 kernel contains the same 
features as 2.4.16 with the only difference beeing bug-fixes
or if there have been added new features. By using a numbering scheme 
that is consistent across both development and
production kernels, it is easier to identify the features in a kernel.

I realize that this is a lot easier to do when you are using a source 
code repository than by hand administration.
I think the time has come for the kernel to find it's way into a cvs 
form. It has to be done, sooner or later, why not now when the 2.5
kernel has been forked?

And I do agree with people who has asked for a bug system to identify 
the various bugs and their fixes.

I have been looking forward to the 2.5 kernel because I have wanted to 
get involved in the kernel devlopment, but have not
wanted to jump in on an existing production/development kernel. The most 
confusing part today is all the various patches
beeing sendt around on the lkml. A lot of people who wants to develop, 
do not have the time to keep on top of the
mailing list. We do have other jobs too, that pays for our food and 
clothes. This is done on our spare time and having
to spend a few hours every day, reading through the kernel list and 
applying various patches seems like a waste
of time. Unless a different system is devised, I think I will stay away 
from the kernel development and
concentrate on other things.

I'm sorry if this seems like a flame-bait, it was not intended to be and 
I did not intend to offend anyone either. My apologies to
anyone who feels so.

-- 
Regards
Svein Erik

I've given up reading books; I find it takes my mind off myself.
_____________________________________________________________
Svein Erik Brostigen       e-mail: svein.brostigen@oracle.com
Senior Technical Analyst                  Phone: 407.458.7168
EBC - Extended Business Critical
Oracle Support Services
5955 T.G. Lee Blvd
Orlando FL, 32822

Enabling the Information Age Through Internet Computing
_____________________________________________________________

The statements and opinions expressed here are my own and
do not necessarily represent those of Oracle Corporation.

Re: Release Policy [was: Linux 2.4.16 ]

[Allan Sandfeld]

On Tuesday 27 November 2001 09:02, Svein Erik Brostigen wrote:
>
> What really scares me is not so much the way the kernels are numbered as
> the way features gets added to
> the kernels.
> Internally in Oracle we do not add new features to a release number,
> just bug-fixes.
> Hence 2.4.0 is the base release of the 2.4.x kernel series. the minor
> x-number should just indicate a bug-fix
> release. Thus, no new features should get added to the 2.4 kernel with
> this numbering schema.
> If you really want to add features into the 2.4.x kernel, you also need
> to extend the numbering schema.
> I.e 2.4.0.x wil then be the bug-fix releases and  2.4.1.x will have new
> features.
> This makes it easier to maintain and to understand what is happening
> between the various releases.
>
> As far as I can understand, today, new features are added to a released
> kernel without any sensible numbering scheme
> identifying this fact. I don't know if a 2.4.10 kernel contains the same
> features as 2.4.16 with the only difference beeing bug-fixes
> or if there have been added new features. By using a numbering scheme
> that is consistent across both development and
> production kernels, it is easier to identify the features in a kernel.
>
The problem is that for kernels new features _are_ bug-fixes. Like the new 
vm, work-around for discovered bugs in hardware, etc., etc. 
I an way what should't be done in a -rc release is new fixing features, but 
only the fixing _of_ features. ;-)

Re: Release Policy [was: Linux 2.4.16 ]

[Svein Erik Brostigen]

Allan Sandfeld wrote:

>On Tuesday 27 November 2001 09:02, Svein Erik Brostigen wrote:
>
>>What really scares me is not so much the way the kernels are numbered as
>>the way features gets added to
>>the kernels.
>>
>The problem is that for kernels new features _are_ bug-fixes. Like the new 
>vm, work-around for discovered bugs in hardware, etc., etc. 
>I an way what should't be done in a -rc release is new fixing features, but 
>only the fixing _of_ features. ;-)
>
Hmmm... workarounds are not new  features, but bug-fixes ;-)
The new vm is not a *new* feature, it is just a different vm than the 
old. Even if you treat it as a new
feature, it should then be incorporated into a new-feature release, i.e 
not in a 2.4.10.4, but maybe in what
would have been a 2.4.11.0.

I'm not going to be anal about this, but a more structured way of 
handling new features/bug-fixes and release
numbering would be nice. A lot easier to know what you are programming 
against and what you are
installing/testing.


-- 
Regards
Svein Erik

I've given up reading books; I find it takes my mind off myself.
_____________________________________________________________
Svein Erik Brostigen       e-mail: svein.brostigen@oracle.com
Senior Technical Analyst                  Phone: 407.458.7168
EBC - Extended Business Critical
Oracle Support Services
5955 T.G. Lee Blvd
Orlando FL, 32822

Enabling the Information Age Through Internet Computing
_____________________________________________________________

The statements and opinions expressed here are my own and
do not necessarily represent those of Oracle Corporation.

Re: Release Policy [was: Linux 2.4.16 ]

[Alex Bligh - linux-kernel]

--On Monday, 26 November, 2001 4:18 PM -0500 Gregory Maxwell 
<greg@linuxpower.cx> wrote:

> Why not just disguard this sillyness of alphabetic characters in version
> numbers

Express version numbers as a real number. Only the versions with
perfectly accurate binary representations of irrational numbers
will be bug-free release candidates :-p

--
Alex Bligh

Re: Release Policy [was: Linux 2.4.16 ]

[Sven Vermeulen]

On Mon, Nov 26, 2001 at 04:18:02PM -0500, Gregory Maxwell wrote:
> Why not just disguard this sillyness of alphabetic characters in version
> numbers... Just carry through the same structure used by major/minor:
> I.e.
> 
> 2.0.39 < released 2.0.39
> 2.0.39.1.1 < first development snapshot of the kernel which will eventually
> 	     be 2.0.40
> 2.0.39.1.2 < second
> 2.0.39.1.n < Nth
> 2.0.39.2.1 < first RC
> 2.0.39.2.2 < second RC
> 2.0.39.3.1 < opps! Development went too long and we had to break feature
> 	     freeze to add important features.
> 2.0.39.4.1 < Trying to stablize again
> 2.0.39.4.2 < a few more bugs fixxed
> 2.0.40	   < Looks like 2.0.39.4.2 got it right!

Some people may find this more "logical", but imho most will find it
confusing... It's already difficult to inform someone about the
(number).(even|odd).(release)-(patch|pre-final) scheme. I'm more into 
	-pre: added some features, bugfixes etc...
	-fc : feature-freeze, only bugfixes
and having some time (f.i. 48h) between the last -fc and the "real" release
(without having a single addendum to the ChangeLog).

Just my 2 cents,
	Sven Vermeulen

-- 
Some people have told me they don't think a fat penguin really embodies
the grace of Linux, which just tells me they have never seen a angry
penguin charging at them in excess of 100mph. They'd be a lot more
careful about what they say if they had. ~(Linus Torvalds)

Re: Release Policy [was: Linux 2.4.16 ]

[Ian Molton]

On a sunny Tue, 27 Nov 2001 15:43:23 +0100 Sven Vermeulen gathered a sheaf
of electrons and etched in their motions the following immortal words:

> 	-fc : feature-freeze, only bugfixes

Did it occur to anyone here that fc is an acronym for 'Feature Creep' ?

:-)

Re: Release Policy [was: Linux 2.4.16 ]

[John Alvord]

On Tue, 27 Nov 2001 15:43:23 +0100, Sven Vermeulen
<sven.vermeulen@rug.ac.be> wrote:

>On Mon, Nov 26, 2001 at 04:18:02PM -0500, Gregory Maxwell wrote:
>> Why not just disguard this sillyness of alphabetic characters in version
>> numbers... Just carry through the same structure used by major/minor:
>> I.e.
>> 
>> 2.0.39 < released 2.0.39
>> 2.0.39.1.1 < first development snapshot of the kernel which will eventually
>> 	     be 2.0.40
>> 2.0.39.1.2 < second
>> 2.0.39.1.n < Nth
>> 2.0.39.2.1 < first RC
>> 2.0.39.2.2 < second RC
>> 2.0.39.3.1 < opps! Development went too long and we had to break feature
>> 	     freeze to add important features.
>> 2.0.39.4.1 < Trying to stablize again
>> 2.0.39.4.2 < a few more bugs fixxed
>> 2.0.40	   < Looks like 2.0.39.4.2 got it right!
>
>Some people may find this more "logical", but imho most will find it
>confusing... It's already difficult to inform someone about the
>(number).(even|odd).(release)-(patch|pre-final) scheme. I'm more into 
>	-pre: added some features, bugfixes etc...
>	-fc : feature-freeze, only bugfixes
>and having some time (f.i. 48h) between the last -fc and the "real" release
>(without having a single addendum to the ChangeLog).

The bug-fixes only would have to be tightly defined. All of
2.4.0-2.4.15 were bug-fixes in some sense... 

john

Re: Release Policy [was: Linux 2.4.16 ]

[Michel Angelo da Silva Pereira]

	I agree with your opinion, it's so difficult to understand what is 
happening with the linux kernel.
	And the -rc (Release Candidate) it's not welcome, remember me another OS 
in development status.

Bye

Sven Vermeulen wrote:

> On Mon, Nov 26, 2001 at 04:18:02PM -0500, Gregory Maxwell wrote:
> 
> 
> Some people may find this more "logical", but imho most will find it
> confusing... It's already difficult to inform someone about the
> (number).(even|odd).(release)-(patch|pre-final) scheme. I'm more into 
> 	-pre: added some features, bugfixes etc...
> 	-fc : feature-freeze, only bugfixes
> and having some time (f.i. 48h) between the last -fc and the "real" release
> (without having a single addendum to the ChangeLog).
> 
> Just my 2 cents,
> 	Sven Vermeulen
> 
> 


-- 
=================================================
Borges & Rinolfi Soluções em Redes Corporativas
Security Officer
Profissional Certificado Conectiva Linux
www.techs.com.br/kidmumu - UIN 4553082 - LC 83522

... e querido papai do céu, em vez de botar as vitaminas no óleo de
bacalhau, bota nos merengues que seu Manoel tem lá na venda. Amém.
=================================================

Re: Release Policy [was: Linux 2.4.16 ]

[Bjoern A. Zeeb]

On Mon, 26 Nov 2001, Chris Meadors wrote:

> I like the ISC's release methods.  The do -rc's (-pre's would be fine for
> the kernel as it is already established), each -rc fixes problems found
> with the previous.  When an -rc has been out long enough with no more bug
> reports they release that code, WITHOUT changes.

Hi,

I am neither a vendor nor maintainer nor a great kernel hacker but I
think you all miss at least one point (what I for sure do too):

The problem is that you kernel hackers out there fetch the pre stuff
and test it that others run test cycles on them ... .  But the
lot of people out there will never fetch anything else than
a "release" ; no -pre no -rc no -ac no whatever prefix or suffix.
You will not get them just because somebody 's changing the name
to something else.

Make your test periods longer. If there are no real serious bug in the
pre let the pre live for a week or 2 or even longer. Who cares ? We are in
'stable' branch at the moment! At some (early) point of pre-releases
stop accepting any further features and if the -pre gets real close to being
fine announce that it'll be the last one, make a note to the changelog,
wait another week for seriuos bufixes and then release the tarballs
(or if any have one more pre).

There are for sure some points that there should be better no
more different naming conventions: hpa will surely have to hack up more
scripts, things might get inconsistent between different stable/dev.
versions, we already have the -<some letter> releases for other kernel
hacker's releases like -aa -ac, ... and so on...
But if you really decide on another suffix my vote would be -rc 'cause
it's the most common one (perhaps linus then will use it in the future
too ?)

And always keep in mind: another new 'release' is nothing else than
another 'release candidate' to the next version with hopefully less
bugs more stability (and sometimes more features ;)

just my 5 cents

-- 
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

Re: Release Policy [was: Linux 2.4.16 ]

[J.A. Magallon]

On 20011126 Bjoern A. Zeeb wrote:
>
>The problem is that you kernel hackers out there fetch the pre stuff
>and test it that others run test cycles on them ... .  But the
>lot of people out there will never fetch anything else than
>a "release" ; no -pre no -rc no -ac no whatever prefix or suffix.
>You will not get them just because somebody 's changing the name
>to something else.
>

The problem is the fear of people about -ac or -pre series. What should
be done is to teach people that what they think is kernel 2.4.8 from
RedHat or Mandrake is really 2.4.8-ac7 or the like. They are shipping
-ac versions (beacuse of preferences and driver update, usually are
-ac series and not -pre series). So your 'distro rock solid kernel'
is an -ac kernel (and I do not say that an -ac kernel is not rock
solid, I have run -ac's until 13-ac7).

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.16-pre1 #1 SMP Sun Nov 25 02:06:34 CET 2001 i686

Re: Release Policy [was: Linux 2.4.16 ]

[Andrew Morton]

Marcelo Tosatti wrote:
> 
> (people are flooding me with patches, btw, please stop for a while).
> 

That's funny.  The rest of us haven't seen these patches.

Marcelo, if someone sends you a patch which has not been thoroughly
reviewed on the appropriate mailing list, I would urge you to
peremptorily shitcan it.  There is no reason why you alone should
be responsible for reviewing kernel changes.

-

Re: Release Policy

[David S. Miller]

   From: Andrew Morton <akpm@zip.com.au>
   Date: Mon, 26 Nov 2001 17:04:02 -0800
   
   Marcelo, if someone sends you a patch which has not been thoroughly
   reviewed on the appropriate mailing list, I would urge you to
   peremptorily shitcan it.  There is no reason why you alone should
   be responsible for reviewing kernel changes.

Are you suggesting that, for example, I should send every Sparc change
to this list?

I bet a lot of what he is seeing are driver and arch updates.

Such updates really only need to go through his "stupid filter"
when it is coming from the maintainer, but it does add up and
take up time.

Re: Release Policy

[H. Peter Anvin]

Followup to:  <20011126.171301.50592818.davem@redhat.com>
By author:    "David S. Miller" <davem@redhat.com>
In newsgroup: linux.dev.kernel
>
>    From: Andrew Morton <akpm@zip.com.au>
>    Date: Mon, 26 Nov 2001 17:04:02 -0800
>    
>    Marcelo, if someone sends you a patch which has not been thoroughly
>    reviewed on the appropriate mailing list, I would urge you to
>    peremptorily shitcan it.  There is no reason why you alone should
>    be responsible for reviewing kernel changes.
> 
> Are you suggesting that, for example, I should send every Sparc change
> to this list?
> 

appropriate != this.

> I bet a lot of what he is seeing are driver and arch updates.
> 
> Such updates really only need to go through his "stupid filter"
> when it is coming from the maintainer, but it does add up and
> take up time.

Obviously.  If it's for a maintained subsystem:

a) if it's from the subsystem maintainer, sanity-check it.
b) if it's not, dump it or reject with the appropriate notice.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Release Policy

[Anuradha Ratnaweera]

On Mon, Nov 26, 2001 at 05:32:18PM -0800, H. Peter Anvin wrote:
> > 
> > Such updates really only need to go through his "stupid filter"
> > when it is coming from the maintainer, but it does add up and
> > take up time.
> 
> Obviously.  If it's for a maintained subsystem:
> 
> a) if it's from the subsystem maintainer, sanity-check it.
> b) if it's not, dump it or reject with the appropriate notice.

A minor issue...

How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from
the subsystem aintainer himself?  I mean anybody would have sent any crap, but
not too bad enough to suspect.  But if it came with a CC to a list, there is a
much smaller chance of this happenning.

Yes.  This would be very rare and the effects would be very short lived.  But
still the _possibility_ exists.

Cheers,

Anuradha

-- 

Debian GNU/Linux (kernel 2.4.13)

When you make your mark in the world, watch out for guys with erasers.
		-- The Wall Street Journal

Re: Release Policy

[H. Peter Anvin]

Anuradha Ratnaweera wrote:

> 
> A minor issue...
> 
> How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from
> the subsystem aintainer himself?  I mean anybody would have sent any crap, but
> not too bad enough to suspect.  But if it came with a CC to a list, there is a
> much smaller chance of this happenning.
> 
> Yes.  This would be very rare and the effects would be very short lived.  But
> still the _possibility_ exists.
> 


How about sending a quick reply "got your patch, applied it?"  The 
maintainer can then say "WHAT PATCH?"

	-hpa

Re: Release Policy

[Anuradha Ratnaweera]

On Mon, Nov 26, 2001 at 11:40:30PM -0800, H. Peter Anvin wrote:
> Anuradha Ratnaweera wrote:
> > 
> > How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from
> > the subsystem aintainer himself?  I mean anybody would have sent any crap, but
> > not too bad enough to suspect.  But if it came with a CC to a list, there is a
> > much smaller chance of this happenning.
> > 
> > Yes.  This would be very rare and the effects would be very short lived.  But
> > still the _possibility_ exists.
> 
> How about sending a quick reply "got your patch, applied it?"  The 
> maintainer can then say "WHAT PATCH?"

Don't we need a consistent indexing system for patches?

May be the subsystem maintainers can upload patches to some place over ssh/ssl
and the maintainer can _download_ them from there. The maintainer will simply
email the patch number and not the whole thing. And patches can be
numbered/named in some consistent manner.  Once the system is in place, we can
even automate md5 checksums etc.

Cheers,

Anuradha

-- 

Debian GNU/Linux (kernel 2.4.13)

There's one consolation about matrimony.  When you look around you can
always see somebody who did worse.
		-- Warren H. Goldsmith

Re: Release Policy

[Harald Arnesen]

Anuradha Ratnaweera <anuradha@gnu.org> writes:

> How does Marcelo (or Linus or Alan, say) know that the patch
> _really_ came from the subsystem aintainer himself?

They could reject patches that came without the maintainers GPG or PGP
signature.
-- 
Hilsen Harald.

Re: Release Policy

[Keith Owens]

On Tue, 27 Nov 2001 11:08:04 +0100, 
Harald Arnesen <gurre@start.no> wrote:
>Anuradha Ratnaweera <anuradha@gnu.org> writes:
>
>> How does Marcelo (or Linus or Alan, say) know that the patch
>> _really_ came from the subsystem aintainer himself?
>
>They could reject patches that came without the maintainers GPG or PGP
>signature.

Unfortunately the normal GPG/PGP signing changes '-' at start of line
to '- -', even with clear text signing, and destroys the patch.  You
have to use --not-dash-escaped in GPG, where the man page says:

--not-dash-escaped
  This  option changes the behavior of cleartext signatures so that
  they can be used for patch files. You should not send such an armored
  file via email because all spaces and line endings are hashed too.
  You can not use this option for data which has 5 dashes at the
  beginning of a line, patch files don't have this. A special armor
  header line tells GnuPG about this cleartext signature option.

I don't know if PGP accepts text signed by GPG with --not-dash-escaped
nor do I know if there really is a problem with mailing such patches.
But the warning above is nasty enough to rule it out.  The only other
option for signed patches is uuencode or MIME (with or without
compression) and Linus does not like that format.

Re: Release Policy

[Mike Fedyk]

On Tue, Nov 27, 2001 at 09:29:36PM +1100, Keith Owens wrote:
> On Tue, 27 Nov 2001 11:08:04 +0100, 
> Harald Arnesen <gurre@start.no> wrote:
> >Anuradha Ratnaweera <anuradha@gnu.org> writes:
> >
> >> How does Marcelo (or Linus or Alan, say) know that the patch
> >> _really_ came from the subsystem aintainer himself?
> >
> >They could reject patches that came without the maintainers GPG or PGP
> >signature.
> 
> Unfortunately the normal GPG/PGP signing changes '-' at start of line
> to '- -', even with clear text signing, and destroys the patch.  You
> have to use --not-dash-escaped in GPG, where the man page says:
> 
> --not-dash-escaped
>   This  option changes the behavior of cleartext signatures so that
>   they can be used for patch files. You should not send such an armored
>   file via email because all spaces and line endings are hashed too.
>   You can not use this option for data which has 5 dashes at the
>   beginning of a line, patch files don't have this. A special armor
>   header line tells GnuPG about this cleartext signature option.
> 

Interesting.

> I don't know if PGP accepts text signed by GPG with --not-dash-escaped
> nor do I know if there really is a problem with mailing such patches.
> But the warning above is nasty enough to rule it out.  The only other
> option for signed patches is uuencode or MIME (with or without
> compression) and Linus does not like that format.
> 

But we're not dealing with Linus with 2.4 anymore.  Maybe Marcello will
accept signed compressed patches.  With a few modifications, most MUAs that
support external processing could be setup to verify the sig, uncompress,
and view in the message area.

MF

Re: Release Policy

[Jes Sorensen]

"David S. Miller" <davem@redhat.com> writes:
> Are you suggesting that, for example, I should send every Sparc change
> to this list?
> 
> I bet a lot of what he is seeing are driver and arch updates.
> 
> Such updates really only need to go through his "stupid filter"
> when it is coming from the maintainer, but it does add up and
> take up time.

A real problem is the large number of driver patches that come in
from non maintainers.

Jes

Re: Release Policy

[Giacomo Catenazzi]

Harald Arnesen wrote:

> Anuradha Ratnaweera <anuradha@gnu.org> writes:
> 
> 
>>How does Marcelo (or Linus or Alan, say) know that the patch
>>_really_ came from the subsystem aintainer himself?
>>
> 
> They could reject patches that came without the maintainers GPG or PGP
> signature.
> 

Why? If the patch seem to come from a maintainer AND the quality of
patch is ok, why to require some other 'burocratic' steps?

	giacomo