A long time ago there was a similar problem, at that time the solution
was splitting the kernel into development and stable version. Maybe it
is time to reconsider the way stable kernels are updated.
Just remember that we've been around this block before. In the 1.2
days, the people who liked the stable kernels were happy. The people
who wanted the latest drivers, the latest enhancements, etc. for their
"production" servers, were screaming and yelling at us because 1.2
didn't have their favorite feature.
In 2.0, there was an attempt to try to move some of the more critical
features back from 2.1 into to 2.0 --- for example, the SYN flooding
defenses, since it was claimed that productions Linux servers absolutely
needed this production.
Then people complained that this destablized the kernel. In response,
developers were slow to get 2.0.31 out, until it had received the proper
testing.
Now people are complaining that 2.0.31 is taking so long....
Given this kind of abuse, is it any wonder that people like David might
decide that it's simply not worth his time and effort? People are
screaming at you no matter what you do, and very few people are showing
their appreciation. It's a no-win situation.....
I don't know the solution. Maybe new stable kernel revisions should be
dubbed 'beta' versions, the 'beta' being removed when the kernel
proves to be stable in public usage for a few weeks. Maybe never
releasing a new version without a plethora of pre-patches is it. Or
even re-releasing 2.0.29 as 2.0.31 and 2.0.30-pre2 as 2.0.32-pre, thus
removing 2.0.30 from the 'market' solves the problem for now.
You're assuming that people will use the the beta versions. (Instead of
being spoiled brats who don't do anything and just complain, complain,
commplain.....) We already have the 2.0.30-pre2 release; if people
don't test it with the name 2.0.30-pre2, will changing the name help?
- Ted