Re: Shortening the Development Cycle... [maybe OffTopic, flame-bait?]

Wade Hampton (whampton@staffnet.com)
Fri, 10 Sep 1999 12:23:12 -0400

Joe wrote:
>
> [snip]
> The issue seems to be how do we keep the stable kernels stable,
> yet keep porting back new features in to stable kernels from the
> developmental kernels, yet still decrease the development cycle.
Mutually exclusive goals for the most part....
>
> Here is my proposal (reject it, flame it, I have a delete button
> too ..lol)
>
> Maybe the stable kernls should not contain the new features by
> default. Just do fixes on the stable kernel and then rather than
> integrating the backports into the stable kernel by default,
> have them as "feature patches" (I think somone else suggested
> this too). Then someone who upgrade a stable kernel by default
> gets only bug fixes, and if they want extra or additional
> features then they can get extra patches for this feature.
> This would hopefully keep stable kernels stable.
> The feature patches would not have to be 'supported' under
> stable kernels, but woudl be worked on under development
> kernels.
This sounds reasonable for most features, except that some of the
newer features would not get exercised. However, since newbies and
commercial users usually use the "stable" series, this would
be a safe approach.

As Linux gets more attention by commercial entities, the press,
Wall street, etc., there is more visibility, hence more
pressure to have a VERY stable product. Remember, whether we like
it or not we are in competition with Microsoft and hence a
target for them -- including FUD, millions of $ of it.
>
> As for development kernels:
> Deadlines. Why do you tink companies have them? So that they can
> say by this time such and such is done. Rather than useing a
> date, why not use a version number? Lets say 2.3.20 (pick one) .
> If you stuff is not in by that version number it does not get in
> this round. Then from 2.3.20 the kernel can be working on for
> fixes rather than new features. This means that hopefully by the
> time it reaches 2.3.25(?) it is stable enought to be released as
> 2.4. When 2.4 is released then 2.5 can start and stuff that was
> not in in 2.3.20 can go into 2.5.

Maybe goals like:
1. all features in by 2.2.20
2. bug fixes until about 2.2.25 or 30 then declare a "beta kernel"
and ask for extensive testing
3. user testing/bug fixes for 2 months or so
4. release the production kernel after extensive user testing

Also, how about a kernel-kit for beta testers, including:
- file system check software (like someone on the list asked for)
- memory test software
- network test software
- required upgrades (e.g., for NFS)
[yes I know, many of these exist, but why not put them in a package?]

This plus a beta kernel could be used to exercise it prior to its
relase.... The more testers the better.

> This should help reduce the development life cycle.
Hopefully.
>
> This is just my 2 cents, take it leave it but I'd personally
> rather have a stable 2.2 then new features and support for P3
> optimizations. Some drivers can be added into the kernel without
> being a config option (vmware does this and cpia does this), so
> if the need for new drivers is an issue this is an option.
2.2 has been out for what, nearly 9 months and some of us (myself
included) are having stability problems with it....

My 2 cents -- flames >/dev/null

Cheers,

-- 
W. Wade, Hampton  <whampton@staffnet.com>


-
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/