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).
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?
> 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.
> 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!
> 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.
[...]
> "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.
> 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.
-- 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- 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:18 EST