On Tue, 11 Jan 2000, Horst von Brand wrote:
> Date: Tue, 11 Jan 2000 16:14:23 -0300
> From: Horst von Brand <vonbrand@pincoya.inf.utfsm.cl>
> To: Marco Colombo <marco@esi.it>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: Standard Development Integration
>
> Marco Colombo <marco@esi.it> said:
> > On Tue, 11 Jan 2000, Horst von Brand wrote:
>
> [...]
>
> > Well, right now most of the work is on getting 2.3 stable, i hope.
>
> Designing last changes in the infrastructure, shaking out bugs in said
> design, completing cutover to new ways of doing things, migrating drivers,
> integrating changes to non-ia32 architectures. Then getting it real stable
> (perhaps a month or two). Then 2.4, let's say two to three months of 2.4
> shakedown, then start 2.5.
>
> > 2.3 won't be THE experimental release forever (and shouldn't be right now,
> > BTW). Read your last sentence again, and it's what i'm really proposing.
> > Call 2.3 'the stable one' and 2.5 'the experimental release' and you get
> > what i'm asking for. Probably it can't be done in a day, since 2.3
> > is not ready today to be called 'the stable release'. But i think that's
> > the way to go.
>
> Calling the current 2.3 2.4 won't make it stable. And nobody wants the 2.0
> fiasko again: Let 2.3 mature before it gets to be 2.4, and let's hope for
> at most 2.4.12 or so (like we are getting with 2.2).
Agreed. I'm not saying to make the move tomorrow. I'm just saying to
make the todo list as shorter as possible, by removing items, and have it
stable as soon as possible.
>
> Besides the problem with not enough hackers for the developement work, if
> you fragment the development you are also fragmenting the testers, and this
> definitely has negative impact on the kernel too.
>
> [...]
>
> > > OK, give us a copy of Linus and the head hackers, and they take over the
> > > other branch.
>
> > As you wrote, they're already 'on the other branch'. Just ban all non
> > working features from 2.3, and go for stability only.
>
> Junk PCI, ISA; drop TCP/IP and firewalls. Many network drivers are broken
> too, so kill a bunch of them. SCSI needs work... but that went out the
> window with ISA and PCI, no further loss. PCMCIA won't go, no RAID, no
> USB. Maybe salvage a filesystem or two, get rid of memory management. Plus
> distributions are screwed as initrd and RAMdisks don't work either... Not
> much left, is there?
Yup. I just wonder why there's so much work to be done. My answer is that
2.3 came out too late, with many people developing on 2.2. So they've been
late with 2.3.
>
> > In a short time
> > we can have a quite stable 2.4pre (without many wanted but still new
> > features).
>
> That "short time" is what you will have to wait for 2.4, the development
> _is_ in flux. No new features, just fixing what is in now. Ripping it out
> for your proposal is probably more work than finishing it up, and the
> result would be a 2.2 plus a few features that could be backported if
> really needed.
Probably you know better that me. But what i'm suggesting is not really
for 2.3, but for 2.5. I think it's a mistake to start it after 2.4 is out.
I'm just saying to start new DEVEL tree as soon as (almost) you stop
the previous one. How this maps to 2.3 now its not the real matter.
The problem here is not 2.3 being late or incomplete. The problem is a
2.2 that has been used as a development release because 2.3 was not there.
So the development effort went on 2.2 based features instead of going to
2.3.
>
> > At that time start 2.5 and be ready to put all the new code
> > in it. In six months (remember, numbers here are just placeholders) we can
> > have a 2.6 (or 3.0 whatever) with the new features. I'm more willing
> > to wait 6 months for a 2.6+everything and have 2.4 quite soon than to
> > wait 4 months for 2.4+everything.
>
> Why wait? What your proposal would give is plain 2.2 + a few features -
> stability. Go for 2.2!
You mean 2.2 + some patch to add new features. Ok.
But 2.2 is meant to be stable. Patching it possibly breaks stability.
I have to chose: having a stable kernel, WITHOUT new features, or spend
some time in testing the patched kernel. Maybe i even find some bug,
report it, patch again and so on. I find myself somewhat actively
involved in kernel develpment. Wow. Bad news is that the kernel i'm
working on is 2.2 NOT 2.3. Well, if the new feature we're talking about
is something that migrates smoothly to 2.3, that's fine. But that's
not true for many things.
I mean, no one should provide new features for 2.2, unless they are
backported from 2.3. Of course, you are free to patch the kernel you
like. But in the past people were *forced* to chose 2.2 as their
development kernel, since there was no 2.3 kernel yet. As a result,
now we have to face the fact that 2.3 has less working features than
2.2. If this comes from it's own evolution, is good. If this comes from
the fact that people were forced to invest time on 2.2 instead of 2.3,
that's bad. 2.3 has less working *NEW* features. 2.4 is going to have
less features than a 2.2 + misc patches.
Say i want feature 'X'. In a perfect world, feature 'X is completely
modular, and so even if it was developed on 2.3, it work on 2.2, too.
Feature 'X' is quite stable, and will be in 2.4. I can use it and i'm
happy. I can chose to test 2.3, for i like to give my 0.02c to it,
and still have feature 'X'. It's my choice.
Suppose now that for some reason, 'X' is not really modular to
the kernel. So BEING DEVELOPED ON 2.3, i'm forced to install a 2.3
kernel and test it. Or live without it, if stability is my major concern.
Every effort i make to test it goes in the right direction as it helps
the development of both 2.3 and features 'X'. That's the right price to
pay, and the main reason an OSS project is successful.
Right now, for some feature 'X', i'm *forced* to use 2.2. Not only
i don't have to pay the price (as in the perfect world), but i can't
pay it even if i want to, as on 2.3 feature 'X' does not work. Instead
of forcing people to contribute to 2.3 development, you're forcing them
not to.
> > Of course that's my personal taste.
> > Still it sounds good to me to stop adding new features to 2.3 now and
> > add them to a baby named 2.5.
>
> The changes people have been developing in the wings that did not go into
> 2.3 now (and so probably won't ever be in 2.4) are being developed in
> parallel (as private patches, whatever), they will surface when 2.5 comes
> out, and hopefully be integrated in due time. No slowdown there, just the
> visible head hackers slaving away at the _massive_ work of stabilizing and
> cleaning up the mess.
Parallel development works fine, provided the various branches share a
common root. I'm just saying this root should have been 2.3 instead of 2.2,
and should be 2.5 instead of 2.4 in the future. Having feature 'X' which
works well under 2.2, because was developed on it, and does not compile or
work on 2.3 and won't make it for 2.4 is quite a nonsense.
You should use 2.2 to develop applications, not kernel parts.
> [...]
>
> > "Wild" development will go on on ONE branch only, of course. Getting
> > 2.3 stable enough to call it 2.4 is not exactly "wild development"...
>
> But it is a lot of work. Not exactly sexy, but it has to be done.
Sure. I didn't mean to say it's little work.
> > I'm not an expert, but i can see there are some difficulties in porting
> > from 2.2 to 2.3. I'm not speaking of generic drivers, but of some of the
> > JFS code (Ext3 and ReiserFS).
>
> This is not "porting", it is designing the right infrastructure and putting
> it in place so that stuff like journalled filesystems can be integrated
> seamlessly. Work that has been postponed for 2.5, with the agreement of the
> respective authors.
That's the right decision. But when will they see the first 2.5?
What should they do meanwhile? Keep on testing on 2.2? Spending time
to make it work with 2.3/4? So when we have 2.4.12 and 2.5.35, we will
have working JFSes on the 2.4 series, as separate patch-sets (but will
be 'not so tested' features on a 'stable' kernel) and still much work
to be done to integrate them in 2.5.
'Designing the right infrastructure' is an early stage in development,
i think.
If they're doing it now, it's better to do it on a kernel which is in
it's early stage. I simply don't think 2.3 is the good place for it.
2.5 is its right place, i agree. But can this step be delayed until 2.5
is out, given the 'standard' release cycle? That means 6 months at least,
IMHO.
My proposal is to have 2.5 start at the time of 2.4.0 or even some 2.4pre
instead of 2.4.[56], which is 3-4 months earlier. That's all. I'm not saying
it should happen 'soon'. But i think that it follows. An earlier 2.5 will
ease the pressure of getting some new features included in 2.4, letting
developers focus on making it stable. At the same time, developers that
are working on new features will have 2.5 to play with.
> --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>
.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:20 EST