********* ***************** ********** **** ***** ***** ************
To subject Re: Standard Development Integration
peter@cadcamlab.org (Peter Samuelson) wrote:
********** ******************** ****** ******** ******* *************
> > 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.
What keeps me from supporting the development branch with RSBAC patches:
For a spare time programmer it is difficult to keep up with the speed of
changes, e.g. my patch against 2.3.29 failed at about half the places (!)
in 2.3.33.
I rather wait for the change speed to calm down before porting, ending up
in mostly supporting stable branches. For me that seems better than
spending so much time with porting that could be spent with improving the
feature itself.
So yes, as soon as things get going many patches break and often take much
time to fix.
> 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?
It's even worse: I already started #ifdef'ing within the 2.2 branch,
because otherwise it simply doesn't compile. This means rechecking code
with older kernel versions within a branch, too.
So there is another choice: As soon as a new stable series starts,
developer changes over to that, simply skipping the development branches.
This is not desirable, but much easier to handle.
> > 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.
It would help a lot to have some list of changes, specially when things
have to be done in a completely different way. Possibly with a how-to for
upgrading. (No, sorry, I don't have the time myself to document other
people's code.)
All the changes tend to pile up to a huge amount of porting work - maybe a
discussion about the features to be added within a development branch
should be held before feature freeze time...
Amon.
-- Please remove second ao for E-Mail reply - no spam please! ## CrossPoint v3.11 ##- 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 23 2000 - 21:00:19 EST