"Kenneth C. Arnold" <kcarnold@yahoo.com> said:
> In-Reply-To: <00052819143200.01194@tabby>; from pollard@cats-chateau.net on Sun
> ***, May 28, 2000 at 06:50:14PM -0500
> > >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?
Alan Cox already told you it's too buggy to ship right now.
> > umm ... did you want it to work too?
> Yes... but I think more people would try the devel kernels if they were
> only for a few specific additions. That would be more people reporting
> and fixing bugs. And it worked a while ago.
Who gets to say which "few additions" go in? Also note that though there
are "few visible additions" in 2.4, internally much has been reworked, much
has been axed and redone, new subsystems as support for future development
have been designed and integrated. That does take time, and most of the 2.3
cycle has been dictated by those changes, not primarily by the adding and
integration of the visible features.
> > That isn't enough time. Remember, a lot of the developers work on their
> > own time and are not paid. This can cause a lot of time gaps where they
> > just can't work on it. This also means that short cycles also cause
> > rework since they can't keep up easily. (thats my problem)
> That's an organizational problem, not a time cycle problem as I see it.
There is no "organization" that could be called this in linux kernel
development...
> > Short version cycles also mean that there are few distinguising
> > features that will show up in a version.
> But the stuff that is _there_ doesn't need to wait for a backport to
> work.
The "stuff that is there" needs to mature and exhaustive testing before
being let loose on the unsuspecting world... and that takes time. Linux is
characterized by very high quality, and fast bug fix turnaround. The
software engineering truism is that software can have attributes of fast
delivery, high quality, and low cost. You can pick at most two... and "low
cost" (meaning scarce qualified development manpower) is forced on the
process by its very nature and goals. Which one of the others do you
prefer?
> > Besides, the short cycle IS being done - thats what the x.y.z numbering
> > is for. The z field changes very rapidly (especially in the
> > development versions). The even y field values are for stable feature
> > releases. The x field for major feature updates.
> Yes, but z+1 is not necessarily more stable than z with odd y. My idea is
> to have relatively few kernels for which z+1 is less stable than z. Get
> all the new features (read, bugs) in that are going to go in in a few
> months, not a few years, and work on the new features later.
Noble idea, that one. But the world doesn't work that way. Many features
mean major changes in the kernel, only rather trivial ones (yet another PCI
network or sound card, for instance) can be done in a short period of
time. Sure, much new stuff could be kludged on in a few months, which is
the path other OSes followed. They then sunk under the weight of the
patches over short or longer time, even in the face of heroic efforts to
save them.
Besides, all this has been discussed regularly (say once a year) on l-k, no
real new arguments on either side have showed up in a long time.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- 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:20 EST