How is that a copout? The problem was noticed. I am only suggesting
that we not be in such a hurry to put code in the production kernels
until we are pretty sure it works well enough, and that we release
major production versions more often so that they do not contain 2 or
3 years worth of new code making it so hard to debug. We probably
should have had 2 or 3 code freezes and production releases since
2.2.x. As I mentioned in a previous posting, this way we do not have
to run a 2 or 3 year old kernel in order to have reasonable stability.
> > Here are some of the problems I see:
> > There was far to long of a stretch with to much code dumped into both
> > the 2.2 and 2.4 kernels before release. There needs to be a smaller
> > number changes between major releases so that they can be more
> > thoroughly tested and debugged. In the race to get it out there they
> > are making the same mistakes as Microsoft, releasing production
> > kernels with known serious bugs because it is taking to long and they
> > want to move on forward. I enjoy criticizing Microsoft so much for
> > the same thing that I do not want to have to stop in order to not
> > sound hypocritical :-). The Linux community has built a lot of it's
> > reputation on not making these mistakes. Please lets try not to
> > destroy that.
> > They are disregarding the even/odd versioning system.
> > For example:
> > There was a new 8139too driver added to the the 2.4.5 (I think) kernel
> > which Alan Cox took back out and reverted to the old one in his
> > 2.4.5-ac? versions because it is apparently causing lockups.
> > Shouldn't this new driver have been released in a 2.5.x development
> > kernel and proven there before replacing the one in the production
> > kernel? I haven't even seen a 2.5.x kernel released yet.
> > Based on Linus's original very good plan for even/odd numbers, there
> > should not have been 2.4.0-test? kernels either. This was another
> > example of the rush to increment to 2.4 long before it was ready.
> > There was a long stretch of test kernels and and now we are all the
> > way to 2.4.5 and it is still not stable. We are repeating the 2.2.x
> > process all over again. It should have been 2.3.x until the
> > production release was ready. If they needed to distinguish a code
> > freeze for final testing, it could be done with a 4th version
> > component (2.3.xx.xx), where the 4 component is incremented for final
> > bug fixes.
> Sorry, I disagree with every last bit. Either you accept a situation
> or you try to do something about it.
I am spending a lot of time testing new kernels, reporting bugs and
offering suggestions that I think may improve on the stability of
production kernels. Is this not considered doing something about it?
It is necessary to point out where one sees a problem in order to
offer possible solutions for improvement.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/