On Thu, 13 Jan 2000, Horst von Brand wrote:
> Date: Thu, 13 Jan 2000 20:14:02 -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:
>
> [...]
>
> > See the 'First draft list of 2.3.x "Things to fix"' thread.
> > Alan really meant "things to fix", but it quickly became "things to do".
>
> What others dream of having in 2.4 doesn't decide what will be in. Alan was
> asking for comments, for pieces that might be deleted from the list (too
> green, too much work) and others that he might have missed and should be
> added. Haven't seen a "Second draft" nor "Final list" from him anyway.
It doesn't matter what will be in. The fact is people need/want/demand/dream
of new features. They want them in 2.3/4 not just ASAP (subtle difference,
which is the point).
The points are:
1) there's an huge demand of new features in a soon-to be-released kernel,
because everybody knows that we have to wait almost a year for the following
release. I don't mean this pressure comes from end users only.
Commercial distributions should take care of them (and they do). But
also developers want their work to be released as part of the standard
kernel, sooner or later. See pressure on relaxing the meaning of a
'feature-freeze' or 'stable kernel'. And that's not just ego: a large
user base is required for the final debugging phase, to produce rock-stable
software. This pressure tends to delay further the final release of
new kernels, short-circuiting to 1).
2) as a reaction to 1), some developers go on indipendently, expecially
if their devel-cycle di out of sync with Linus' one. If they're at
30% of the initial implementing phase when Linus calls a feature-freeze,
right now they have no other choice, if they want to go on working.
Since it makes a lot of sense for them to keep their patches up to
date with kernel patchlevels, in the end they find themselves working
on the lastest *stable* kernel, say 2.2. Eventually, when they're
at 95% of development, and need some extensive testing, they make a
public release. A new feature appears for a *stable* kernel. Meanwhile,
the new main kernel devel branch (2.3) appears. If it does not break
their code, they're lucky, and may go on in fixing bugs, and have a
stable piece of software on 2.2 and (with little effort) on 2.3 (later
on 2.4). But changes in 2.3 may even force them to choose: either
go back to implementation phase (or even re-design something), throwing
away some or most of the work already done, or ignore 2.3 and go on
debugging. The first choice is the best in the long term, of course,
since they get in sync with the main kernel development cycle, but
i think most would choose the second one, and i don't blame them
for that. We end up with a feature thats work great on 2.2 and is not
there on 2.3. This too raises the pressure on delaying 2.3/4,
short-circuiting to 1) again.
3) Pressure in 2) in not just a lot of messages posted on this list in
"I want this/that" threads. It's also that: "i do want to do some
testing, but since i need/like feature 'X' that is a 2.2 only thing,
i can't test 2.3", while it should be right the opposite: "if you want
the cool feature 'X', you have to help in testing 2.3". This slows
down the process of getting 2.3 to 2.4. Sorry, this slows down *A LOT*
the process.
Just imagine that the new RAID and ReiserFS are available for 2.3 only
(and that they work together B-)). To make a public release of them,
both Redhat and Suse (to name just two) should put much effort on
getting some 2.3.xx stable enough to be released. This leads necessarily
to a faster development of 2.3.
Right now 2.3 has less features that 2.2. That's not only because of its
internal changes that broke drivers/modules/fs's and the like (that's
part of the devel process) but also because some features were developed
on 2.2, when 2.3 was not available.
Having an earlier appearance of the 2.5 branch, say before 2.4.0,
will probaly lead to other problems (e.g. Linus and other being overloaded,
the press being confused), but will help solving 1), 2) and 3) now, and,
above all, avoiding they happen again for 2.5 itself, IMHO.
I don't understand if you think that 1), 2) and 3) are not happening, or
you don't see them as problems, or you don't think that my idea on facing
them is good...
> --
> 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:24 EST