Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

(Short?) merge window reminder

 

 

First page Previous page 1 2 3 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded


w.landgraf at ru

May 24, 2011, 6:40 AM

Post #26 of 57 (2897 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

Version numbers should not be only numerology, but
connected to quality or progress. Comparing the situation
of the 1, 2.0, 2.2, 2.4, 2.6 versions, since starting 2.6
, the progress of the kernel, and also the situation of
Linux as a whole and of its use changed very. Exactly in
the last subversions with many new hardware
modules/drivers the quality improved very. At the same
time, the subversions becomes too much since the last new
version. Thus, it's time for 2.8 or even 3.0 in order to
mark this very improved quality and use of Linux since the
start of the 2 and 2.6 versions. wl
---
Professional hosting for everyone - http://www.host.ru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


j.glisse at gmail

May 24, 2011, 7:09 AM

Post #27 of 57 (2903 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Tue, May 24, 2011 at 9:40 AM, werner <w.landgraf [at] ru> wrote:
> Version numbers should not be only numerology, but connected to quality or
> progress.  Comparing the situation of the 1, 2.0, 2.2, 2.4, 2.6 versions,
> since starting 2.6 , the progress of the kernel, and also the situation of
> Linux as a whole and of its use changed very.  Exactly in the last
> subversions with many new hardware modules/drivers the quality improved
> very.  At the same time, the subversions becomes too much since the last new
> version.  Thus, it's time for 2.8 or even 3.0 in order to mark this very
> improved quality and use of Linux since the start of the 2 and 2.6 versions.
>    wl
> ---

If i were to give my feeling, and i am doing it right now, i wish that
such version change to be backed with things like removal of dead code
for instance in the GPU side we would like at one point to drop non
KMS path and delete a whole bunch of files and dead API in the process
(at least that's on my bad santa list). Non KMS is in survival mode,
at this point we try to not break it but we don't give shit about it.
Bug against it are redirected to the closest black hole.

Cheers,
Jerome
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

May 24, 2011, 7:41 AM

Post #28 of 57 (2902 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

> If we change from 2.6.X to 3.X, then if we don't change anything else,
> then successive stable release will cause the LINUX_VERSION_CODE to be
> incremented. This isn't necessary bad, but it would be a different
> from what we have now.

I think I prefer 3 digits. Otherwise we will have to pass 3.0, 3.1 and
3.11 all of which numbers still give older sysadmins flashbacks and will
have them waking screaming in the middle of the night.

Also saves breaking all the tools and assumptions people have been used
to for some many years

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

May 24, 2011, 7:43 AM

Post #29 of 57 (2895 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

Can we drop most of MCA, EISA and ISA bus if we are going to have a big
version change ? A driver spring clean is much overdue and it's all in
git in case someone wishes to sneak out at midnight and bring some crawly
horror back from the dead.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ralf at linux-mips

May 24, 2011, 7:48 AM

Post #30 of 57 (2898 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Mon, May 23, 2011 at 07:17:21PM -0400, Ted Ts'o wrote:

> > So I'm toying with 3.0 (and in that case, it really would be "3.0",
> > not "3.0.0" - the stable team would get the third digit rather than
> > the fourth one.
>
> If we change from 2.6.X to 3.X, then if we don't change anything else,
> then successive stable release will cause the LINUX_VERSION_CODE to be
> incremented. This isn't necessary bad, but it would be a different
> from what we have now.

It will require another bunch of changes to scripts that try to make sense
out of kernel Linux version numbers. It's a minor issue and we might be
better off doing something else than version number magic. Not last a
new major version number raises expectations - whatever those might be.

Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jonsmirl at gmail

May 24, 2011, 8:07 AM

Post #31 of 57 (2896 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Tue, May 24, 2011 at 10:43 AM, Alan Cox <alan [at] lxorguk> wrote:
> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
> version change ? A driver spring clean is much overdue and it's all in
> git in case someone wishes to sneak out at midnight and bring some crawly
> horror back from the dead.

2.8 could mark the beginning of the great cleanup
--- work out the details of what needs to be cleaned and set a goal
--- remove old buses/driver, switch to device tree, graphics, 32/64
merges, etc
3.0 would mark its completion

--
Jon Smirl
jonsmirl [at] gmail
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


albertpool at solcon

May 24, 2011, 8:35 AM

Post #32 of 57 (2902 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

A new major version number will reach high expectations. I think it's
better to wait till the power issues of 2.6.38/39 are fixed and proved
to be absent, before naming it Linux 3.0.
Anyway, wouldn't it be a great date to release Linux 3 on August 21,
2011? I know it's hard to achieve this exact date with a stable 3.0. If
you don't think a fixed date for a stable version is a good idea, you
could release the first RC of 3.0 on that date.

About the scripts: if they don't like the version number to be 1 digit
shorter, why not append an extra .0 to uname? This digit can be used for
bugfix releases, like 2.6.38.7. In the current system, an extra digit is
added for those releases. But if that extra digit will always be there,
and is 0 by default, scripts won't care about the lack of a 3rd digit.
Then, the 3.0 will be 3.0.0, with new releases (current 3rd digit) being
3.1.0, 3.2.0, ..., and bugfix releases (current 4th digit) being 3.0.1,
3.0.2, .... It might be a bit confusing after the switch, but if we
change to a 2-digit number, it's confusing too.
Scripts recognizing bugfixes as new releases is a smaller disaster than
scripts crashing or returning errors due to the lack of a 3rd digit.

I agree with Jon Smirl that it could be probably better to release 2.8
first, but there's also a good side on switching to 3.0. We are skipping
2.7, that means our version numbering system already changes a bit. Why
not change it completely then?

Sorry if I've missed out some discussion about this, I am not
subscribed. I have only read some messages in the LKML archive.

Albert Pool

On Tue, May 24, 2011 at 15:48:39 +0100, Ralf Baechle wrote:

On Mon, May 23, 2011 at 07:17:21PM -0400, Ted Ts'o wrote:

> > So I'm toying with 3.0 (and in that case, it really would be "3.0",
> > not "3.0.0" - the stable team would get the third digit rather than
> > the fourth one.
>
> If we change from 2.6.X to 3.X, then if we don't change anything else,
> then successive stable release will cause the LINUX_VERSION_CODE to be
> incremented. This isn't necessary bad, but it would be a different
> from what we have now.

It will require another bunch of changes to scripts that try to make sense
out of kernel Linux version numbers. It's a minor issue and we might be
better off doing something else than version number magic. Not last a
new major version number raises expectations - whatever those might be.

Ralf


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ralf at linux-mips

May 24, 2011, 8:46 AM

Post #33 of 57 (2891 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote:

> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
> version change ? A driver spring clean is much overdue and it's all in
> git in case someone wishes to sneak out at midnight and bring some crawly
> horror back from the dead.

Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a
few others still refuse hard to die.

Is it worth to setup a system to track success / failure reports for
drivers and ditch drivers once there are no success reports for a driver
for too long? It may not be a good idea - people tend not report success
much more rarely than failure.

(On that matter, I wonder if there are 5.25" USB floppy drives ...)

Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jengelh at medozas

May 24, 2011, 10:29 AM

Post #34 of 57 (2898 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Tuesday 2011-05-24 17:46, Ralf Baechle wrote:
>On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote:
>
>> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
>> version change ? A driver spring clean is much overdue and it's all in
>> git in case someone wishes to sneak out at midnight and bring some crawly
>> horror back from the dead.
>
>Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a
>few others still refuse hard to die.
>
>Is it worth to setup a system to track success / failure reports for
>drivers and ditch drivers once there are no success reports for a driver
>for too long? It may not be a good idea - people tend not report success
>much more rarely than failure.
>
>(On that matter, I wonder if there are 5.25" USB floppy drives ...)

If there were, they would appear as Mass Storage devices (at least
the 3.5" USB floppy gadgets do), and as such, don't depend on ISA
or the classic floppy driver at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

May 24, 2011, 10:36 AM

Post #35 of 57 (2900 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On 05/24/2011 08:07 AM, jonsmirl [at] gmail wrote:
> On Tue, May 24, 2011 at 10:43 AM, Alan Cox <alan [at] lxorguk> wrote:
>> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
>> version change ? A driver spring clean is much overdue and it's all in
>> git in case someone wishes to sneak out at midnight and bring some crawly
>> horror back from the dead.
>
> 2.8 could mark the beginning of the great cleanup
> --- work out the details of what needs to be cleaned and set a goal
> --- remove old buses/driver, switch to device tree, graphics, 32/64
> merges, etc
> 3.0 would mark its completion
>

I think this whole discussion misses the essence of the new development
model, which is that we no longer do these kinds of feature-based major
milestones. If we want to to deprecate lots of drivers (which I
personally would advocate against -- I have built systems specifically
to run a real floppy drive since the Linux floppy driver is amazingly
flexible and can read/write a lot of formats that nothing else can,
including USB floppies) then we should do that in the normal course of
action, incrementally, and listed in feature-removal-schedule.txt, not
all at once due to some arbitrary milestone.

We have found it works better this way.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

May 24, 2011, 10:41 AM

Post #36 of 57 (2907 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin <hpa [at] zytor> wrote:
>
> I think this whole discussion misses the essence of the new development
> model, which is that we no longer do these kinds of feature-based major
> milestones.

Indeed.

It's not about features. It hasn't been about features for forever.

So a renumbering would be purely about dropping the numbers to
something smaller and more easily recognized. The ABI wouldn't change.
The API wouldn't change. There wouldn't be any big "because we finally
did xyz".

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


lisa at ltmnet

May 24, 2011, 11:06 AM

Post #37 of 57 (2891 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would get the third digit rather than
> the fourth one.

How about stardates? That'd make a release made now 64860.8

I really should sleep more...

--
Lisa Milne <lisa [at] ltmnet>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ms at citd

May 24, 2011, 11:34 AM

Post #38 of 57 (2893 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On 23.05.2011 13:33, Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar <mingo [at] elte> wrote:
> >
> > I really hope there's also a voice that tells you to wait until .42 before
> > cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would get the third digit rather than
> the fourth one.

What about strictly 3 part versions? Just add a .0.

3.0.0 - Release Kernel 3.0
3.0.1 - Stable 1
3.0.2 - Stable 2
3.1.0 - Release Kernel 3.1
3.1.1 - Stable 1
...

Biggest problem is likely version phobics that get pimples when they see
trailing zeros. ;-)




Bis denn

--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


eschvoca at gmail

May 24, 2011, 11:48 AM

Post #39 of 57 (2901 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds
<torvalds [at] linux-foundation> wrote:
> On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin <hpa [at] zytor> wrote:
>>
>> I think this whole discussion misses the essence of the new development
>> model, which is that we no longer do these kinds of feature-based major
>> milestones.
>
> Indeed.
>
> It's not about features. It hasn't been about features for forever.
>
> So a renumbering would be purely about dropping the numbers to
> something smaller and more easily recognized. The ABI wouldn't change.
> The API wouldn't change. There wouldn't be any big "because we finally
> did xyz".
>

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>

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.

Using the date also clearly communicates it is not about features.
When there is a 3.0 (4.0) release people expect big new features and
API/ABI breakage.

My 2 cents.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


david at lang

May 24, 2011, 11:55 AM

Post #40 of 57 (2897 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Tue, 24 May 2011, Matthias Schniedermeyer wrote:

> On 23.05.2011 13:33, Linus Torvalds wrote:
>> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar <mingo [at] elte> wrote:
>>>
>>> I really hope there's also a voice that tells you to wait until .42 before
>>> cutting 3.0.0! :-)
>>
>> So I'm toying with 3.0 (and in that case, it really would be "3.0",
>> not "3.0.0" - the stable team would get the third digit rather than
>> the fourth one.
>
> What about strictly 3 part versions? Just add a .0.
>
> 3.0.0 - Release Kernel 3.0
> 3.0.1 - Stable 1
> 3.0.2 - Stable 2
> 3.1.0 - Release Kernel 3.1
> 3.1.1 - Stable 1
> ...
>
> Biggest problem is likely version phobics that get pimples when they see
> trailing zeros. ;-)

since there are always issues discovered with a new kernel is released
(which is why the -stable kernels exist), being wary of .0 kernels is not
neccessarily a bad thing.

I still think a date based approach would be the best.

since people are worried about not knowing when a final release will
happen, base the date on when the merge window opened or closed (always
known at the time of the first -rc kernel)

in the thread on lwn, people pointed out that the latest 2.6.32 kernel
would still be a 2009.12.X which doesn't reflect the fact that it was
released this month. My suggestion for that is to make the X be the number
of months (or years.months if you don't like large month values) between
the merge window and the release of the -stable release. This would lead
to a small problem when there are multiple -stable releases in a month,
but since that doesn't last very long I don't see a real problem with just
incramenting the month into the future in those cases.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


emil.langrock at gmx

May 24, 2011, 12:06 PM

Post #41 of 57 (2899 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


napohybelskurwysynom2010 at gmail

May 24, 2011, 1:59 PM

Post #42 of 57 (2894 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

Hi,

2011/5/24 Lisa Milne <lisa [at] ltmnet>:
>> So I'm toying with 3.0 (and in that case, it really would be "3.0",
>> not "3.0.0" - the stable team would get the third digit rather than
>> the fourth one.
>
> How about stardates?

This is a wonderful idea! :)

> That'd make a release made now 64860.8
>
> I really should sleep more...
>
> --
> Lisa Milne <lisa [at] ltmnet>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo [at] vger
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



--
Slawa!
Zimny Lech z Wawelu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jengelh at medozas

May 24, 2011, 2:05 PM

Post #43 of 57 (2902 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

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.

"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.)


>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.)

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


My 2円.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


luto at MIT

May 24, 2011, 2:25 PM

Post #44 of 57 (2899 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On 05/23/2011 04:33 PM, Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar<mingo [at] elte> wrote:
>>
>> I really hope there's also a voice that tells you to wait until .42 before
>> cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would get the third digit rather than
> the fourth one.
>
> But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a
> fairly nice round number.
>
> There's also the timing issue - since we no longer do version numbers
> based on features, but based on time, just saying "we're about to
> start the third decade" works as well as any other excuse.
>

I don't think year-based versions (like 2011.0 for the first 2011
release, or maybe 2011.5 for May 2011) are pretty, but I'll make an
argument for them anyway: it makes it easier to figure out when hardware
ought to be supported.

So if I buy a 2014-model laptop and the coffee-making button doesn't
work, and my favorite distro is running the 2013 kernel, then I know I
shouldn't expect to it to work. (Graphics drivers are probably a more
realistic example.)

Also, when someone in my lab installs <insert ancient enterprise distro
here> on a box that's running software I wrote that needs to support
modern high-speed peripherals, then I can say "What? You seriously
expect this stuff to work on Linux 2007? Let's install a slightly less
stable distro from at least 2010." This sounds a lot less nerdy than
"What? You seriously expect this stuff to work on Linux 2.6.27? Let's
install a slightly less stable distro that uses at least 2.6.36."


--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpj at urpla

May 24, 2011, 4:00 PM

Post #45 of 57 (2898 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Monday 23 May 2011, 22:33:48 Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar <mingo [at] elte> wrote:
> > I really hope there's also a voice that tells you to wait until .42
> > before cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would get the third digit rather than
> the fourth one.
>
> But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a
> fairly nice round number.
>
> There's also the timing issue - since we no longer do version numbers
> based on features, but based on time, just saying "we're about to
> start the third decade" works as well as any other excuse.

But hey, do you really want to release a Linux 3.0 kernel without
serious layered filesystem functionality?

Shame on you,
Pete

PS.: Sorry for being such a pest in this regard, but filesystem layering
is one of the most important missing bits to excel out of the box in
* live distros
* diskless computing
* flash based systems
Even the linux based commercial PBX solution (mobydick), I bought, ships
with it.
PPS.: Bad timing, I know, but I'm glad, that Al is back to life again..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


Valdis.Kletnieks at vt

May 24, 2011, 6:13 PM

Post #46 of 57 (2899 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Tue, 24 May 2011 14:30:59 +0200, Jacek Luczak said:
> 2011/5/24 Jan Engelhardt <jengelh [at] medozas>:
> > On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
> >
> >>Another advantage of switching numbering models (ie 3.0 instead of
> >>2.8.x) would be that it would also make the "odd numbers are also
> >>numbers" transition much more natural.
> >>
> >>Because of our historical even/odd model, I wouldn't do a 2.7.x -
> >>there's just too much history of 2.1, 2.3, 2.5 being development
> >>trees.
> >
> > .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
> > become pretty much apparent that they are not devel.)
> >
> >>And then in another few years (probably before getting close to 3.40,
> >>so I'm not going to make a big deal of 3 = "third decade"), I'd just
> >>do 4.0 etc.
> >
> > While 2.6 has certainly worn out, already thinking of a 4.0 is highly
> > reminiscient of the version number arms race Firefox and ChromeBrowser
> > are doing currently.
> >
> >>Because all our releases are supposed to be stable releases these
> >>days, and if we get rid of one level of numbering, I feel perfectly
> >>fine with getting rid of the even/odd history too.
> >
> > If I remember past-time discussions right, ELF was the contributing
> > factor to bump the major number to 2.0 back then; ever since 2.0, no
> > similarly breakthrough-ing event has occurred.
>
> What then about BKL removal? Nice place to celebrate with version jump
> and heaving some beers.

Well, if we're looking at ELF-sized ABI changes, how about 3.0 be the
release where we re-sync the syscall numbers on all the archs? ;)


porpen at gmail

May 24, 2011, 9:47 PM

Post #47 of 57 (2900 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

Hi,

On Mon, May 23, 2011 at 12:13:29PM -0700, 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.

With all the discussion about matching the year, keeping the numbers smallish and breaking build/test scripts...

Why not match the year this way: v2.11 = 2011

So, to get there, how about:
v2.6.39 current
v2.6.40
v2.7.? (see below)
v2.11.0 sometime this year maybe or skipped.
v2.12.? early 2012.
v2.13.? early 2013.
and so on...

To hell with making the months match up to anything. IMHO, that's micromanaging BS that will cause recurring troubles forever.

Advantages:
-Build & test scripts won't break for a while. (see note about this below)
-Major and Minor numbers together approximately match the year of release.
-Subreleases don't get too big. e.g. with 2 week releases, v2.12.x might reach .26 or .27 and resets with v2.13.0

Disadvantages:
-in the year 2100 the version will have to leap to v21.0 and that numbering will last until v29.99 or so.
-most of us won't live long enough to see v31.14 or v42.0

The build scripts would finally break in the year 25500 with the step after kernel v254.99.?. I suspect one of our decendants in the next 23.5 thousand years can figure out how to fix that.

IMHO, this may be a least effort compromise between the keep-numbers-small camp, the match-the-year camp and the don't-break-scripts camp.

Of course, math junkies like me would love to see v2.7.18.28 at some point in the process. Could we jump straight to that just before we leap to v2.11.0 or whatever numbering is chosen please?

-phil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


emil.langrock at gmx

May 25, 2011, 2:12 AM

Post #48 of 57 (2894 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kasperd at nhnxn

May 25, 2011, 5:26 AM

Post #49 of 57 (2893 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On 24/05/11 21.13, Valdis.Kletnieks [at] vt wrote:
> Well, if we're looking at ELF-sized ABI changes, how about 3.0 be the
> release where we re-sync the syscall numbers on all the archs? ;)

If you want to do that I think the best way to do it is to
have both the old and the new numbers co-exist through the
3.x series and the old ones go away in 4.0.

You'd first have to find the highest number currently
assigned and then add a bit of safety margin to decide on
a starting point for the new numbers.

Should architecture dependent system calls be assigned
from a separate interval where they could overlap between
architectures? Or should they be assigned from the same
sequence as other calls and return -ENOSYS on other
architectures than the one they were targeted for?

Or was it all a joke, and you don't actually want that
cleanup to happen because of too much breakage?

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,11,_+2,_+7,_+6);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jkosina at suse

May 25, 2011, 5:52 AM

Post #50 of 57 (2893 views)
Permalink
Re: (Short?) merge window reminder [In reply to]

On Tue, 24 May 2011, Andy Lutomirski wrote:

> Also, when someone in my lab installs <insert ancient enterprise distro
> here> on a box that's running software I wrote that needs to support
> modern high-speed peripherals, then I can say "What? You seriously
> expect this stuff to work on Linux 2007? Let's install a slightly less
> stable distro from at least 2010." This sounds a lot less nerdy than
> "What? You seriously expect this stuff to work on Linux 2.6.27? Let's
> install a slightly less stable distro that uses at least 2.6.36."

I hate to jump into this excellent example of bike-shedding discussion,
but anyway ...

Your example doesn't really reflect reality.

It's common for older enterprise distributions to gradually incorporate a
lot of backported code (and most importantly new hardware support
code/drivers) while not upgrading the kernel major version. So yes, you
will in reality get 2.6.16 kernel (at least according to uname) with
libata with newer service packs of SLES 10, for example (and you could
find many of those across distributions).

--
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First page Previous page 1 2 3 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.