Re: Release Policy [was: Linux 2.4.16 ]

[Svein Erik Brostigen <svein.brostigen@oracle.com>]

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.