Re: Standard Development Integration

From: Mike A. Harris (mharris@meteng.on.ca)
Date: Mon Jan 10 2000 - 13:56:46 EST


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.

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.

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.

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.

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

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

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.

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.

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

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

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.

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.

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

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

- 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:16 EST