(Short?) merge window reminder
On Tuesday 24 May 2011 23:05:30 Jan Engelhardt wrote:
> On Tuesday 2011-05-24 20:48, eschvoca wrote:
> >On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote:
> >> It's not about features. It hasn't been about features for forever.
> >
> >Using the date also clearly communicates it is not about features.
>
> On the contrary: Whenever a 2.6.x release was set out the door, there
> was at least one new feature in the cycle. Given the endless manpower
> that seems to trail Linux, that seems unlikely to change in the near
> term.
>
> On "It is not about features" - it is not /just/ about features - it
> is also about fixes, which are equally important, and they also
> warrant a version bump of some sort on their own. Pointing out the
> obvious, the stable serieses.
You are mixing up features based versioning and identifier for versions. Linux
has no feature based concept for most parts of their version number (only the
patch part clearly states: fixes, fixes, fixes). We only need something that
is easily readable and maybe has no extreme weird meaning that leads to false
conclusions. And yes, that is what eschvoca meant and not something like
"linux is stagnating".
> "Fleeing" to date-based version numbering seems like an excuse
> for making way for releases without any change whatsoever.
> (IOW, if there were features/fixes, a non-date based scheme of
> incremental numbers could indicate them already.)
Yes, that is usally the case... release the same source tarball again and
again. I always had that feeling when looking at those wine, ubuntu, gentoo,
ms, texlive, iasl, hugin, u-boot, ... developers. They are doing nothing the
whole day and the marketing department does everything.
> >Me, a nobody end user, would prefer a version number that corresponded
> >to the date. Something like:
> >
> >%y.%m.
> >%Y.%m.
>
> Except that LINUX_KERNEL_VERSION has only 8 bits for each,
> so 2011 is out of range, which would need to kept in mind.
> And a 2-digit spec.. nah that does not feel very 100-year
> proof. (Just look at struct tm.tm_year for the mess 2-digits
> made technically.)
What is LINUX_KERNEL_VERSION? I only know LINUX_VERSION_CODE and
KERNEL_VERSION
And the calculation behind it is following:
(((a) << 16) + ((b) << 8) + (c))
So for KERNEL_VERSION(2,6,40) we would get 0x20628 and for
KERNEL_VERSION(2011,2,0) we would get 0x07DB0200. Of course our
grandgrandgrand...grand children would die in agony in the year 65536.
And maybe (probably the module version check guys will kill me) could use a
compressed version of that without hurding the comparison function in out of
kernel modules. KERNEL_VERSION_Y(a,b) would be defined as
#define KERNEL_VERSION_Y(a,b) ({typeof (a) _a = a; \
typeof (b) _b = b; \
KERNEL_VERSION(_a >> 8, _a & 0xff, _b); })
This would bring us to the year 16777216 before everybody gets punched in his
private parts by the versioning scheme. It is also possible to get more out of
32 bits when we can assume that Linus or his grandgrand...grand children will
never do more than 128 releases a year.
But yes, I aggree not to use 2 digit numbers for years unless we want to
start the y2k+100 problem here.
> >Then users would know the significance of the number and when a vendor
> >says they support Linux 11.09 the user will immediately know if they
> >are up to date.
>
> An added issue with that would be that numbers would not increase in
> same-sized steps anymore and leave gaps. (There would probably be no
> 11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40)
Ok, this is really a good example why we should not use the month for
releases, but an ever increasing number until the first number is also
increased which resets the second number to 0.
Kind regards,
Emil
Re: (Short?) merge window reminder
Linus Torvalds wrote: PS. The voices in my head also tell me that the numbers are getting too big. I may just call the thing 2.8.0. And I almost guarantee that this PS is going to result in more discussion than the rest, but when the voices tell me to do things, I listen. Correct :) I would still prefer the version number change to something like 2011.0 - already proposed at http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux I don't think that it is reasonable to say that it is bad because third party scripts would break - they would break anyway (I would bet that many of them don't expect to see 3.x anyway). And changing now to 3.0 and then incrementing the second one everytime for 10 years will also lead to something like 3.56.7. I would also say that defining the release number using the time of the merge window start/end is easy understandable. 2.6.40 would be the third development cycle this year aka v2011.2 or v2011.2.0 when the patchlevel should always be included. -- Emil Langrock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 24 May 2011 23:05:30 Jan Engelhardt wrote:
On Tuesday 2011-05-24 20:48, eschvoca wrote:
On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote:
It's not about features. It hasn't been about features for forever.
Using the date also clearly communicates it is not about features.
On the contrary: Whenever a 2.6.x release was set out the door, there
was at least one new feature in the cycle. Given the endless manpower
that seems to trail Linux, that seems unlikely to change in the near
term.
On It is not about features - it is not /just/ about features - it
is also about fixes, which are equally important, and they also
warrant a version bump of some sort on their own. Pointing out the
obvious, the stable serieses.
You are mixing up features based versioning and identifier for versions. Linux
has no feature based concept for most parts of their version number (only the
patch part clearly states: fixes, fixes, fixes). We only need something that
is easily readable and maybe has no extreme weird meaning that leads to false
conclusions. And yes, that is what eschvoca meant and not something like
linux is stagnating.
Fleeing to date-based version numbering seems like an excuse
for making way for releases without any change whatsoever.
(IOW, if there were features/fixes, a non-date based scheme of
incremental numbers could indicate them already.)
Yes, that is usally the case... release the same source tarball again and
again. I always had that feeling when looking at those wine, ubuntu, gentoo,
ms, texlive, iasl, hugin, u-boot, ... developers. They are doing nothing the
whole day and the marketing department does everything.
Me, a nobody end user, would prefer a version number that corresponded
to the date. Something like:
%y.%m.stable patch
%Y.%m.stable patch
Except that LINUX_KERNEL_VERSION has only 8 bits for each,
so 2011 is out of range, which would need to kept in mind.
And a 2-digit spec.. nah that does not feel very 100-year
proof. (Just look at struct tm.tm_year for the mess 2-digits
made technically.)
What is LINUX_KERNEL_VERSION? I only know LINUX_VERSION_CODE and
KERNEL_VERSION
And the calculation behind it is following:
(((a) 16) + ((b) 8) + (c))
So for KERNEL_VERSION(2,6,40) we would get 0x20628 and for
KERNEL_VERSION(2011,2,0) we would get 0x07DB0200. Of course our
grandgrandgrand...grand children would die in agony in the year 65536.
And maybe (probably the module version check guys will kill me) could use a
compressed version of that without hurding the comparison function in out of
kernel modules. KERNEL_VERSION_Y(a,b) would be defined as
#define KERNEL_VERSION_Y(a,b) ({typeof (a) _a = a; \
typeof (b) _b = b; \
KERNEL_VERSION(_a 8, _a 0xff, _b); })
This would bring us to the year 16777216 before everybody gets punched in his
private parts by the versioning scheme. It is also possible to get more out of
32 bits when we can assume that Linus or his grandgrand...grand children will
never do more than 128 releases a year.
But yes, I aggree not to use 2 digit numbers for years unless we want to
start the y2k+100 problem here.
Then users would know the significance of the number and when a vendor
says they support Linux 11.09 the user will immediately know if they
are up to date.
An added issue with that would be that numbers would not increase in
same-sized steps anymore and leave gaps. (There would probably be no
11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40)
Ok, this is really a good example why we should not use the month for
releases, but an ever increasing number until the first number is also
increased which resets the second number to 0.
Kind regards,
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
(Short?) merge window reminder
Linus Torvalds wrote: > PS. The voices in my head also tell me that the numbers are getting > too big. I may just call the thing 2.8.0. And I almost guarantee that > this PS is going to result in more discussion than the rest, but when > the voices tell me to do things, I listen. Correct :) I would still prefer the version number change to something like 2011.0 - already proposed at http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux I don't think that it is reasonable to say that it is bad because third party scripts would break - they would break anyway (I would bet that many of them don't expect to see 3.x anyway). And changing now to 3.0 and then incrementing the second one everytime for 10 years will also lead to something like 3.56.7. I would also say that defining the release number using the time of the merge window start/end is easy understandable. "2.6.40" would be the third development cycle this year aka v2011.2 or v2011.2.0 when the patchlevel should always be included. -- Emil Langrock
