On Sun, 28 May 2000, 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?
>>
>> 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.
The development kernels are NOT for production use, don't use them for what
they are not intended for. It may work if the feature MUST be used, but you also
have to accept the occasional failure; and you should not use other features
that are being modified at the same time. I realize that this introduces the
problem of "must use feature X" but feature Y is not yet working and you have
to use Y since X depends on Y; or the functions supporting X also support Y and
the interaction has not been debugged yet. But that is why it is a development
version. I test features that interest me, I don't test others. If I get a
failure I will report it, but that is NOT what I get paid for. I don't use
development kernel versions in production.
>> 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.
Organizational only if you are paying for it. When you don't you eventually
match the development time with the version step. That is what has happened.
The current new features have had to undergo significant redevelopment,
partially due to memory management changes, buffer handling changes, and
identification of functional requirements. This is not a cycle that can be
done "quick". The attempts to support removable devices in USB (and SCSI/IDE)
have altered several low level features that has caused "undesirable" side
effects. Working out the side effects takes time, and can't be done in 2 months.
>> Short version cycles also mean that there are few distinguishing features that
>> will show up in a version.
>
>But the stuff that is _there_ doesn't need to wait for a backport to work.
That depends entirely on the feature. Some features just cannot be back ported.
Short cycles can also introduce a "never change low level functions because it
would take too long to fix the features that depend on them" orientation on
development. There are times it is necessary to take a long time to do
something worthwhile. System security is one such feature. Currently security
functions are still scattered through the kernel. To reorganize that will take
a significant amount of time, and affect nearly every part of the kernel (most
in a minor way). I'm all in favor of enhancing the security.. When these changes
are released via 2.5 (I hope) I will test them. But I won't use them in
production unless absolutely necessary.
>> 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.
In my expierence, the only times this occurs is when a feature is being
redesigned (other than the occasional accident).
Sometimes it is necessary for the long term stability to redesign low level
functions. This introduces instability that can may show up by a non-bootable
kernel, or crashes. This doesn't happen on all platforms - the developers don't
have all combinations of hardware. They will make it work on the one they have.
The changes may work perfectly there, but most other systems may fail. That is
why the development z field may have a "more unstable new version" than
preceding versions. As the testers identify problems and cycle them back to
the developer a new version comes out. Does that mean the new version works
everywhere? No.. it does mean that it works in more circumstances (on a specific
enhancement), but other features are also being worked on. This interaction is
tracked by the z field - none of the kernels HAVE to work, they do redistribute
a common code set that the developers share that allows each to verify updates,
and to testers to check on specific problems.
This has worked surprisingly well for the last 5 years. The biggest problem I
have seen with it is perceptual - It looks like nothing is being done when
reality shows that there is much activity, and directed at a number of features
that have to converge on stability. Predicting when this will occur is not easy
nor is it reliable. It makes beancounters happy to say "First quarter of yyyy"
but it is unreasonable to expect such accuracy.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
Any opinions expressed are solely my own.
-
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:21 EST