[Marco Colombo <marco@esi.it>]
> 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.
So far so good.
> 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.
OK. As long as the new feature is self-contained, it will often be
included in stable patchlevels (marked EXPERIMENTAL). If it isn't, the
developer will have to maintain it in parallel until the next devel
branch is opened up. This is as it should be.
> 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).
This is where your argument breaks down. Did you check patch 2.3.0?
The compressed patchfile is even smaller than its own PGP signature.
In other words, the act of opening a new development branch does not
automatically break things.
Here's what really happens. Status quo:
* developer develops against 2.1.x, then 2.2.0pre
* Linus releases 2.2.0
* developer keeps developing against 2.2.x
* Linus forks 2.3.0
* developer now has a choice: go with the 2.3.x series, or stay with
the 2.2.x series, or #ifdef for both
What you are suggesting:
* developer develops against 2.1.x
* Linus releases 2.2.0pre and 2.3.0
* developer now has a choice: go with the 2.3.x series, or stay with
the 2.2.0pre/2.2.x series, or #ifdef for both
What is the difference, really?
> 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.
As long as you have two separate branches of maintained codebase, you
will have this problem. Developers have the choice: try and keep up
with multiple branches, or not. Your proposal would not change any of
that.
Peter
-
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 : Sun Jan 16 2000 - 07:02:18 EST