Messages in this thread | | | Date | Fri, 14 Jan 2000 12:47:51 +0100 (MET) | From | Marco Colombo <> | Subject | Re: Standard Development Integration |
| |
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/
| |