Re: Slow development cycle

From: Jeff Garzik (jgarzik@mandrakesoft.com)
Date: Sun May 28 2000 - 10:20:11 EST


Arg. Netiquette. Wrap your lines at 72 columns.

"Kenneth C. Arnold" wrote:
>
> My issue is with the length of time between stable kernel releases. Take USB for example. 2.3.x had a relatively stable USB implementation for a while, but other messes prevented USB support from going into a stable kernel for how long? Two years after Windows 98 had support?

Why do you even bother making this comparison? Linux USB support is a
-volunteer effort-. If you want it to proceed more rapidly, hire some
engineers. Or get off your butt and fix existing bugs. Griping about
the pace of USB development is hardly a reasonable example.

If you think Linux, even with current backing, can match Microsoft's
present rate of driver development, you got another thing coming. We'll
get there, but we still have a long way to go.

> My proposal is to shorten the open development time a lot. Feature freeze after maybe 2 months, not 2 years (exact numbers are disputable, but on that order of magnitude). During the next month or month and a half, extensive testing, and no new features, period. The big patches will keep coming nevertheless (e.g., the big VM patch and the stat() changes as discussed earlier), but they should not even be considered to merge into the frozen kernel. Then, during the open development time for the next devel kernel, all these patches can be integrated and fought over. But stop fighting over it after the freeze.
>
> I know for sure that a lot of the kernel developers will not like working this way. I can anticipate the flames already: not enough time to debug stuff, not enough time to consider the merits of patches, too much rush to release that bugs might remain, and others.

Not enough time and never enough kernel developers.

If you are unhappy with the pace of development, there are ways to
accelerate it. Posting RFCs is not one of those ways...

        Jeff

-- 
Jeff Garzik              | Liberty is always dangerous, but
Building 1024            | it is the safest thing we have.
MandrakeSoft, Inc.       |      -- Harry Emerson Fosdick

- 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 : Wed May 31 2000 - 21:00:19 EST