Kernel Summit 2005: Development process and quality assurance

From LWN's 2005 Kernel Summit coverage.

The final session of the 2005 Kernel Summit was dedicated to the development process and what can be done to produce higher-quality kernels. There is a general sense of satisfaction with the "new" (one year old) development model, but also a sense that the quality of the resulting kernels is not quite what it could be.

Andrew Morton started off the discussion by saying how he would like to see things go. Once the 2.6.13 kernel is released, he would like to merge all of the major subsystem trees within one week. The following week would be dedicated to big fixes, then the kernel would go into stabilization mode. There are currently two problems, according to Andrew:

• Many subsystems are waiting too long to merge their changes into the mainline, with the result that they miss many weeks of testing time. Getting those changes in sooner could help testers find some of the bugs which have been slipping through into the stable releases.

• The kernel developers are simply not fixing bugs, even after they have been found. According to Andrew, we have to try harder, to be more diligent.

It was noted that the source management change did not help the situation; Linus stated that the kernel community lost three months as a result of that change. He also thought it was worth noting that the "dot releases" (2.6.x.y) are widely seen as being successful.

To address the problem of patches not being merged early enough in the cycle, it was suggested that a deadline be imposed. One or two weeks after the start of a kernel cycle, only fixes would be accepted into the mainline. One way of enforcing this change would be to cease merging git repositories after that time, and only accept patches sent via mail. Git is not inherently a problem, but it does make it easy to slip large piles of code into the kernel. This step may not be taken, but it does seem likely that some sort of deadline for major merges will be imposed.

Getting developers to fix bugs is a harder problem. There was some talk of ways to make bugzilla work better, but, in the end, it comes down to the developers taking the time to deal with the bugs in their parts of the kernel. Until that happens, kernel releases will likely continue to have more bugs than any of us would like.

Index entries for this article
Kernel	Development model/Kernel quality

---

to post comments

Development process and quality assurance

Posted Jul 20, 2005 7:56 UTC (Wed) by error27 (subscriber, #8346) [Link] (4 responses)

I receive kernel bug reports from their bugzill. I went into the email configuration for bugzilla.redhat.com and set my "users to watch" to kernel-maint@redhat.com.

The RedHat bugzilla is a lot more active than bugzilla.kernel.org.

Redhat doesn't try to debug problems that don't happen in the most recent version of the kernel. Last Friday, they marked all the bugs as "NEEDINFO" and told people to upgrade. Tons of people came back and reported that their bugs were fixed.

It would be cool if more of the distro's got together and used bugzilla. How do Debian based distro's deal with kernel bugs? If a bunch of them decided that bugzilla was useful that would be great.

To be honest Bugzilla search function is useless.

It would be better if the kernel version field was strict
2.[46].\d{1,2}[-.]\w* and there was a bug fixed version. That would make it easier and more accurate to look up all the bugs reported against a specific version.

The emails that bugzilla generates could be improved. It's hard to see what the email is about sometimes because it has huge disclaimers at the top and bottom and in the middle it says "REMOVED ADDED WHAT CC| foo@bar.com". You can't change that if you are set to watch someone who is recieving those notices.

There are a lot of improvements that could be made to bugzilla actually. ;)

Development process and quality assurance

Posted Jul 20, 2005 8:07 UTC (Wed) by error27 (subscriber, #8346) [Link] (1 responses)

Um... I did hit preview but I was too sleepy to read my post apparently.

I was trying to say that I support the idea of bug tracking websites.

Redhat does a better job tracking kernel bugs than bugzilla.kernel.org for two reasons. First Redhat developers actively use their bugzilla. Second they require the bug reports to be more focused in terms of features and kernel versions.

I was also trying to express disapointment with several features in bugzilla. Perhaps if these were fixed more developers would use it.

Also I was going to give a shout out to Adrian Bunk who is a hero and responds to many of the bugzilla reports on bugzilla.kernel.org.

And then I was going to sleep because I can barely keep my head up anymore and certainly can't write coherently.

Development process and quality assurance

Posted Aug 11, 2005 7:46 UTC (Thu) by SlOrbA (subscriber, #29900) [Link]

It's also good to have a look at the user base of these bugzillas (kernel.org and RedHat). I'd bet that RedHat recieves more bug-reports from non-developing users than kernel.org.

I'm not very familiar with Bugzilla administration and there might be a feature for multiple bugzilla-database interaction, but if there isn't there should be. When Open Source keeps on growing and the development has taken the distributed way of doing things with GIT, there also should be distibuted way of handling bug-reporting.

Example: Non-developing user can't mount a usb high-speed storage to distro X. This user then makes bugzilla bug entry to distro X's bugzilla and probably not under kernel, but maybe under nautilus. How is this bug going to find it's way to maintainer of the kernel subsystem in question?

Development process and quality assurance

Posted Jul 20, 2005 14:14 UTC (Wed) by KaiRo (subscriber, #1987) [Link]

> There are a lot of improvements that could be made to bugzilla actually. ;)

One thing is that the kernel still uses bugzilla 2.16.x, while the stable series is at 2.18.3 and 2.20rc1 is out already, which has even more improvements.

Maybe they should think of upgrading to 2.20 once it's out.

Development process and quality assurance

Posted Sep 5, 2005 3:01 UTC (Mon) by horms (subscriber, #10312) [Link]

As someone asked, Debian itself keeps track of kernel bugs in the debian bug tracking system. This is prefered over Bugzilla by many of the Debian developers as it can be manipulated by email - I'm not sure if Bugzilla can do this. In any case you can view the bugs logged against the kernel at:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&...

And yes, there are a lot of them, which IMHO is evidence that the Debian BTS doesn't quite fit what the Debian Kernel Team is doing. For starters, a lot of those bugs don't apply to the current kernels. We are working on some ideas to fix this.

As for other Debian-based distributions, I believe that Unbuntu have their own Bugzilla. I'm not sure about others.

Development process and quality assurance

Posted Jul 26, 2005 16:22 UTC (Tue) by shane (subscriber, #3335) [Link]

"The kernel developers are simply not fixing bugs, even after they have
been found. According to Andrew, we have to try harder, to be more
diligent."

<irony>
Yes, this will work.
</irony>

In my experience, you need to work differently, not harder, to improve.
If you "try harder" you will have a period of improvement, until you
realise that it is, well, hard, and the improvement ends.

Development process and quality assurance

Posted Jul 29, 2005 18:22 UTC (Fri) by rlrevell (guest, #23596) [Link]

IMNSHO Bugzilla sucks. The ALSA team has has great results with Mantis.