On Mon, 10 Jan 2000, Mike A. Harris wrote:
> Date: Mon, 10 Jan 2000 13:56:46 -0500 (EST)
> From: "Mike A. Harris" <mharris@meteng.on.ca>
> To: Marco Colombo <marco@esi.it>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.rutgers.edu
> Subject: Re: Standard Development Integration
>
> On Fri, 7 Jan 2000, Marco Colombo wrote:
>
> >> We drop features into 2.3.x until its roughly where we want it. Linus then
> >> starts getting very hard to get new features past and the stuff is stabilised
> >> then it pops out probably as 2.4 and we start 2.5 a while later.
> >
> >I've always wondered, why start 2.5 later? Just spawn the 2.5 branch
> >when 2.4.0-pre appears. So development needs not to stop.
> >I think that there's so much pressure on putting features inside 2.3 now
> >(wasn't it feature-freezed?) because 2.6 is SO far away that many can't
> >just wait for it.
>
> That is a good idea from the perspective of a developer like
> yourself, and others, however...
>
> Linus is one man. Linus and other developers only have so much
> time. Keeping track of the devel tree right now (2.3.x) and
> maintaining the stability and patching 2.2.x is a very time
> consuming job. That is why Alan Cox handles 2.2.x right now. If
> we were to start 2.5.x prematurely, it would cause several
> problems:
>
> 1) People would complain because there are WAY too many kernels
> to keep track of. Software developers would be lost. What
> kernel to write for? An FAQ is not enough. People will not be
> happy.
There are only 2 kernels now. 2.2.xx and 2.3.xx. 2.0.xx is somewhat
supported for bug fixes only, and there not much work on it, i think.
When 2.4 is released, active support for 2.2.xx will be dropped anyway.
So there will be only 2 kernels, 2.4.xx and 2.5.xx.
> 2) Driver authors may not want to bother rewriting for 3
> or more different kernels. Keep in mind, 2.0.x is still in very
> widespread use. Developing a driver, or any code at all, that
> will run on 2.0.x, 2.2.x, 2.3.x, 2.4.x, 2.5.x is going to be a
> daunting task for some.
2.0.xx is still in used because diff -r 2.0 2.2 is SO big! There are
years of development of many people. And production boxes need no upgrade,
but for (some) bugfixes. It my DNS server works well under 2.0.38, why
change it?
In pure theory, new drivers should appear only in odd numeber releases,
*before* a feature-freeze. Thanks to the high level of modularity which
the Linux design allows, it's possibile to include some drivers later,
even in the stable branch. But note this is necessary only because there is
a rather long time when the only available kernel for developers is
the "stable" one (forgetting of old releases, and assuming that a post
feature-freeze kernel is NOT avalable for developing).
Of course you have access to old kernels, too.
No one prevents me to write my new distributed-journaled-autorepairing-
autocompressing-autodefragging FS based on 0.99p17, but it think i'll
find some difficulties in porting it to 2.5. B-)
I simply think that *at any time* we should have only 2 kernels:
STABLE and DEVEL. Right now, i would call STABLE the 2.2.xx and DEVEL
2.3.xx, but i'm proposing to switch ASAP to the state where STABLE is
2.4pre and DEVEL is 2.5.
Developers just work on the DEVEL tree. Right now, spawning a 2.5 tree
will cost nothing to developers, as their under-development drivers will
work just fine under 2.5. Otherwise, if they have an almost stable driver,
they will follow 2.3's way to 2.4. If the decide to go for a 2.2 driver,
or a 2.0 driver, they're on their own anyway. Having a small number
of very different kernels (as 2.0, 2.2, 2.4 are now), or many kernels
with smaller changes makes no difference from the developer's point of
view. Supporting more than one kernel will be easier. Supporting many of
them will be a big job anyway.
> 3) If 2.5 were started, some people will ditch 2.3/2.4 and head
> to the new devel branch, perhaps neglecting to maintain their
> older code in the 2.x tree. Alan, et al. can only handle so much
> older stuff on their plate at once.
That's good. If they're adding something new, let's have them jump
directly to 2.5. If their code is stable, they have to maintain it
anyway for 2.4. If they don't, it's their fault.
Alan is not in charge of every piece of code in 2.2.xx.
If some device driver has a bug, let the author fix it. If Alan fixes it,
we thank him, but he's not expected to do so. The core of 2.2.xx should be
completely bug-free (in theory): Alan should just fix bugs that did't
show up in the test phase of 2.2.xx. The same goes for 2.4. It should be
bug-free, or at least that's the goal. My idea is that no kernel development
work should be done on 2.4. Just bug fixing. We can't prevent people
from doing what they want, but we can offer them a better choice, 2.5.
Right now, they have no choice: they're working on 2.3, which (at this
point) is just 2.4 under another name.
> If someone wants to do a "2.5 ahead of time" tree they should
> call it "cuttingedge-linux-pre-2.5.0.tar.gz" and start up a
> website. That way it isn't bunched in with the official kernel.
> When 2.5 official starts, the work done can be merged very
> quickly if Linus, etc.. accept it.
>
> I think this is the best solution anyways... for now.
Exactly. Well, i'm not going to do that. There's a guy out there who showed
excellent capacity in doing that. And it's named Linus.
Such a tree needs someone who knows Linus' mind, since some changes
in 2.5 will be major ones, and probably Linus is already thinking about that.
Many will be design issue. I can't simply do that. I don't know enough
of the kernel to have ideas on it. Someone else could, but those ideas
are likely to be different from Linus' ones.
> >Moreover, when 2.4 is out, there will be no development branch. So people
> >will start developing against it (but wait, shouldn't be a *stable* release?).
> >It already happened (RAID, ReiserFS?) and will probably happen with ext3.
>
> That is because the developers will be spending their time
> stableizing 2.4.x. Unfortunately there are only so many
> developers, and so many man hours.
It's not that simple. Developers "will be spending their time stableizing
2.4.x" if they have something to make stable. But if they're in first
stages of their work, either they stop, or they work against 2.4. And later
this year we will have "The Most Requested Feature of the List" that works
fine on 2.4 and does not even compile on 2.5.
> >Having a 2.5 branch soon also means a 2.6 is coming sooner, and maybe
> >we can have ext3 in it.
>
> No, it doesn't mean 2.6 is coming sooner at all. Developers of
> ext3, and other patches can develop code NOW that will go into
> 2.5 eventually. They do not need to wait for 2.4 to be released
> or for 2.5 to be started.
And their work won't go in 2.5 easily. I'm not foreseeing that.
That's history. People developed against 2.0 and had problems in
porting their work to 2.1. The same happened with 2.2 and 2.3.
> If we start 2.5 now, why not start 2.7 and 2.9 as well? See my
> point? There is only one Linus... Linus is not scalable.
No, sorry i don't see you point. Call it "linux-DEVEL" if you don't
like "2.5". I don't see the need of more than one devel tree. And
i've never said that (or at least never meant that).
And just compiling Linus with SMP support enabled won't help? B-)
> Commercial development often has multiple product cycles on the
> go simultaneously, but I believe stability, and other important
> technical issues get pushed aside from this. Also, different
> project managers likely run the multiple branches leading to
> cross version bugs and inconsistencies. Again, Linus is not
> scalable.
Agreed. Right now, given the great number of changes in 2.3/4, there's
a lot of work in making it stable. But it thinks this comes from
it's late release as 2.3, and late commitment towards 2.4.
I'm proposing the 2.5 spawn to avoid this to happen again at 2.6 time.
> >> > (PS When is ext3 to be introduced?)
> >>
> >> As standard, post 2.4, usably - already.
> >
> >That's it. "post 2.4" means adding it to a "stable" beast.
>
> No it does not. It may mean adding it to 2.4.x sometime, or it
> may mean 2.5.x, 2.7.x, or even never. At any rate, it would be
> marked experimental likely anyways.
It's even more funny. Having a "marked experimental" feature added later
to the stable kernel, i mean.
If it means 2.5.x, pressure will make 2.4 patches appear everywhere.
Unless we can have 2.5.x tomorrow (well, i don't mean exactly 24 hours...).
Early 2.5.xx, with ext3 and ReiserFS, will be usable, but still "marked
as experimental". People will test them, and they will go smoothly in 2.6.
IMHO, first stages of 2.5.xx should aim towards the integration of
pieces of code which were not ready for 2.4. Then, we can have a 2.5.xx
which is quite stable (as 2.3 is now) and appealing to testers.
Then make all the changes you want, and later make it stable again ready
for 2.6. Just some time later you announce the 2.5 feature-freeze,
spawn 2.7.
> >Just put it in 2.5 (very soon) and release it in 2.6 (or
> >backport it to 2.4 in case of huge demand).
>
> You don't get it do you? The AUTHOR of the code says it is NOT
> READY for inclusion for ANY KERNEL. When it is ready for wide
> scale testing and is ready for inclusion, HE WILL SUBMIT IT. At
> that point, Linus will likely accept it in either the devel tree,
> the stable tree, or both as EXPERIMENTAL so long as it doesn't
> touch things all over the place.
Ext3 was just an example. Anyway, the problem is the presence of a
devel tree. There won't be any for a while, since focus is on
making 2.3/4 stable.
> Linus, and other developers don't go looking for cool patches,
> and including them as they see fit. Developers of new things
> wait until they think their code is ready, and THEN submit it for
> POSSIBLE inclusion.
>
> If a 2.5.x tree were started now, it is highly likely that the
> ext3 patches would sit where they are now and not be included
> anyways.
But any changes to 2.5 that may be relevant to ext3 will show up
now, not at the time Ext3 is ready for inclusion. Really, i don't
care much of Ext3, or any other "missing" features. What i need is
ALI support, and i'm pretty comfortable on patching my kernel with
it. I'm not asking for Ext3.
> Face it, you are NOT going to get your ext3 patches in a kernel
> tree just because you want them. The author will submit them
> when he is ready.
Of course. I've never asked for it. Please, just because so many
people do ask for it, don't assume i'm doing the same. They ask
for a STABLE kernel (2.4) with Ext3 in it. I'm asking for a 2.5 spawn.
Completely unrelated (unless you're wondering why Ext3 or other
things are marked as "usable" under 2.2, and not ready for 2.3:
they were developed under 2.2, for the lack of an earlier 2.3).
> >Right now we have NEW features which need to be ported from the
> >(stable) 2.2 branch to the (feature-freezed) 2.3 branch. Weird
> >at least, don't you think so?.
>
> No I don't. I've been following the development for a fair time
> now, and I think that things are proceeding as best they can for
> now. Until Linus accepts some kind of version control software
> for the main kernel tree, and some other changes occur that make
> maintaining the kernel easier (autoconf??) it will likely proceed
> as it is now. Sometimes slow, but that is the way it goes...
>
> Some corporation out there that is that dependant on ext3, or any
> other future feature or enhancement, should hire some of the
> kernel developers, or pay up some big cash to fund faster
> development.
>
> Don't forget, in the mean time, we're all free to add whatever
> patches we like to the kernel.
>
> Start your own fork... like the AC fork, or the ARCA one...
>
> Works for me...
I'd do, if what i needed is just Ext3. But, really, i don't care.
I don't agree things are going on at the best they could. And
it has nothing to do with revision control software or the like.
You said that we're free to add patches to the kernel, but it's true
that we (actually YOU, i've never made up a patch myself, apart from
making broken NE2000 card work, and a one-liner to a ISDN driver)
also need a kernel to patch. Of course you can patch the kernel you like,
even 0.97p13, but it think that a devel kernel should be always there.
Sometime it should spawn a -stable branch, just to make people happy.
And this should happen more often that it happened with 2.0, 2.2 and
(is going to happen with) 2.4.
>
> --
> Mike A. Harris Linux advocate
> Computer Consultant GNU advocate
> Capslock Consulting Open Source advocate
>
> Join the FreeMWare project - the goal to produce a FREE program in
> which you can run Windows 95/98/NT, and other operating systems.
>
> http://www.freemware.org
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:17 EST