Message-ID: <9a8748490706211529yca0588dgd1f7e0b86f7e4a62@mail.gmail.com>
Date:	Fri, 22 Jun 2007 00:29:20 +0200
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"Zoltán HUBERT" <zoltan.hubert@...ero.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Please release a stable kernel Linux 3.0

On 21/06/07, Zoltán HUBERT <zoltan.hubert@...ero.com> wrote:
[snip]
> All people who might read this know that traditionally
> stable releases are even numbered and development branches
> are odd numbered. This changed during late develoment of
> 2.6, according to my analysis because of the "invention" of
> GIT which was itself necessary because of BitKeeper (insert
> ooooooooold flame-wars here) and which allowed very dynamic
> develoment.

Git itself, nor bitkeeper was not the main reason behind the desition
to maintain 2.6.x as the stable kernel going forward.

> While this has been effective, alternative
> voices (Mr Morton complaining that more bugs were added
> than repaired, semi-stable semi-supported 2.6.x.y branches
> where invented...) come more and more into the front.

I myself have argued that we should be focusing more on stability and
regression fixing, but I'm not so sure that a 2.6.7 devel branch would
solve this. In general the 2.6.x.y -stable kernels seem to be doing
the job pretty good.

>The
> upcoming GPL v3 versus v2 debate will make things worse,

How is the GPLv2 vs GPLv3 debate relevant to kernel stability, ABI
stability or anything else of the sort?

> and we all know this. The un-ending stable ABI argument
> goes into this same direction.

What I think you are wishing for is a stable API - which is not going
to happen; please read Documentation/stable_api_nonsense.txt
(http://lxr.linux.no/source/Documentation/stable_api_nonsense.txt).
A stable ABI we already have.

[snip]
> You might think it's easy for me to simply "use" Linux and
> complain while you're doing the hard stuff. As it happens,
> the current development/stable model makes our life as
> "users" more and more difficult.

In what way?

Most users should be using distribution kernels anyway, not vanilla
kernel.org kernels. Those distribution kernels should provide you with
all the stability you require.

>I'm using Linux since 1997
> on a Mac thanks to LinuxPPC-1997, and I'm a hard pusher of
> Linux whenever possible, sometimes against the common
> sense, for example when I favor using National Instrument
> cards with Linux drivers and custom written TCP/IP server
> against easy LabView on Windows. While some of you dislike
> closed source drivers, the choices "we users" face are:
> - closed source drivers with closed source OS
> - closed source drivers with open source OS
> Please consider that we are living in a REAL world, and not
> Disney-Land.
>

As far as I am aware, both nVidia and ATI have closed drivers
available for you to use if you please. And they should work just fine
with most distribution kernels as well as vanilla.


> So I've demonstrated that from a "users" perspective a new
> stable Linux would be of advantage. I'll now list what I
> suggest for this new stable branch:
>
I don't think you have demonstrated that.
How specifically is the current development model hurting you?
What exactely would we gain by switching back to the old
stable/unstable branch model?

[snip]
> Why on earth
> call "kernel object" things that are "kernel modules" ? And
> that every person calls "modules" and not "objects" ? I
> know I know, in UNIX dynamic libraries are .so "shared
> objects", so what ? A "module" is a "module" and NOT an
> "object", call a cat a cat.
>
It sure is an object, it's even called object code. I think the name
suits just fine. In any case, it's just a name.

> Third, while a stable ABI in a dynamically developed kernel
> is a difficult/impossible/unwanted feature,

A stable ABI is very much a wanted feature and one that a lot of work
goes into maintaining.
Note; ABI != API.

> it should be
> possible to implement in a stable branch. This could even
> be a distinction between "stable" and "development"
> branches. And it would certainly help vendors of
> closed-source drivers.
>
If they want to keep their drivers closed they get to do all the hard
work of tracking kernel API changes. Their choice, their problem. I
don't think you'll find very many people on this list who gives a damn
about the troubles of closed source driver developers.

[snip]


-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists