On 08/11/06, Arjan van de Ven <[email protected]> wrote:
> There's no shortage of issues that need fixing, but since we keep
> merging new stuff, a lot of bugfixing energy gets spend on the new
> cool stuff instead of fixing up any other issues we have.
but if you do this you just end up with a bigger backlog so that the
next one will even be more unstable due to a extreme high change rate.
Only if people continue to work on new stuff during the "bug fixing only" cycle.
If we manage to get everyone focused on bug fixing only for the entire
cycle the backlog won't be growing (much).
> Coverity has, as of this writing, identified 728 issues in the current
> kernel. Sure, some of those have already been identified as false or
> ignorable issues, but many are flagged as actual bugs and still more
> are as yet uninspected.
most are mostly false. And the rest is getting looked at. What's the
problem?
Yes, MANY are false, and I know the rest are getting worked at, I work
on some myself when time permits.
I mentioned it simply as an indicator (one amongst many) that we have
a lot of known unfixed issues.
> Adrian Bunk has his list of known regressions and, I'll bet, also some
> patches in the trivial queue for small issues.
and all this fixing is happening AS WELL as new features. What makes you
think suddenly even more fixing will happen?
My point was "get people to suspend their work on new features and
focus entirely on bugfixes for a single cycle", so we get more
manpower working on fixing all those known issues we have before we
move on with new features.
> There are many parts of the kernel that are not documented.
this is where the OSDL Documentation Person will help a lot; a full time
person.
True. I'm looking forward to that.
> I'm sure most distributions have a bunch of bug fixing patches lying
> about that they could push.
I doubt it; most have gotten real good at avoiding getting a huge patch
backlog since that is just incredibly expensive ;)
Ok, maybe I was wrong there.
> - A while back, akpm made some statements about being worried that the
> 2.6 kernel is getting buggier
> (http://news.zdnet.com/2100-3513_22-6069363.html).
and at this years Kernel Summit actual data and general consensus showed
this was unfounded fear; the bugrates are more or less stable, but with
many more users.
Ok, I may be on thin ice here, but that contradicts my personal
experience. I see a lot of very nice improvements in recent 2.6
kernels, but I also see a greater need for careful testing before
deploying on the systems I'm responsible for - I feel that I'm running
into more "whoops that kernel wasn't quite fully baked" situations
recently (and yes, I do try to report and/or fix those issues when I
encounter them).
>
> - The need for the -stable tree and the (relatively large) number of
> -stable releases between each new major release clearly shows that we
> are leaving lots of regressions in our wake.
No it shows that bugs are getting fixed and delivered to you
IMMEDIATELY. Many many of the -stable things fixed are not in new
things. Is there anything in the -stable process that is not working for
you?
Let me make one very clear statement first: -stabel is a GREAT think
and it is working VERY well.
That being said, many of the fixes I see going into -stable are
regression fixes. Maybe not the majority, but still, regression fixes
going into -stable tells me that the kernel should have seen more
testing/bugfixing before being declared a stable release.
All I'm trying to say is that we have a number of known bugs, a number
of known regressions, a number of known inefficiencies. Maybe, just
maybe, we should focus a little more on that and a little less on new
features, new hardware support etc. Not permanently - overall I think
the 2.6 model is working great - but just for a single kernel release
cycle every now and then. And why not just try it once as an
experiment? We'll never know if it's a good idea if we don't try it at
least once.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
