On 21/06/07, Zoltán HUBERT <[email protected]> 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 <[email protected]>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]