Andrew Morton on kernel development [LWN.net]

Andrew Morton on kernel development

Posted Jun 11, 2008 17:27 UTC (Wed) by hmh (subscriber, #3838) [Link]

It may be interesting, unless kernel developers ignore the bug-fix only release and work on new futures by themselves in the meantime.

Which many will do, causing total chaos in the next merge window. That's the reason why it was not done yet, AFAIK.

Now, if we could get a sufficiently big number of kernel regulars (like at least 50% of the ones with more than three patches merged in the last three releases) and all subsystem maintainers (so as to keep the new-feature-craze crowd under control) to pledge to the big bugfix experiment, then it just might work.

Andrew Morton on kernel development

Posted Jun 11, 2008 17:59 UTC (Wed) by proski (subscriber, #104) [Link]

It's not a matter of making developers doing something else. It's a priority thing. Most developers work both on new features and on bugfixes. Sometimes bugs are exposed as the code is modified to include new features.

If some kernel is declared stable, it mean that only bugfixes are accepted. In other words, the merge window is skipped. To make the point, the previous kernel could be tagged as rc1 for the stable kernel.

I don't know it it's going to work, but it may be worth trying once.

Andrew Morton on kernel development

Posted Jun 11, 2008 18:52 UTC (Wed) by grundler (subscriber, #23450) [Link]

> I also gave up on reporting kernel bugs.

I'm sorry to hear that. I know that reporting bugs is alot of work.

> Usually I am the only person with that bug and hardware 
> configuration and nobody will fix it.

If no one else really has that HW, then there could be lots of reasons:
1) They don't care - many developers don't care about parisc, sparc, 100VG or tokenring
networking, scaling up or down (embedded vs large systems),e tc.
2) They don't have documentation for the offending HW.
3) no one else was able to reproduce the bug and it's not obvious what is wrong.

> This is not specific to the kernel though. I think I
> never got any of the bugs which I reported to fedora,
> red hat or gnome fixed.

Before someone else suggests these, maybe the way the bugs are reported has something to do
with the response rate?
There are some good essays/resources out there on how to file useful bugreports. I don't want
to suggest yours are not useful since I've never seen one (or don't know if I have). Just when
you mention problems across all open source projects I wonder.

> Two other things: is the kernel bugzilla used at all?
> are there any tests like unit tests to catch regressions for the kernel?
> both are pretty standard for any other open source project nowadays.

Agreed. But to be clear, the kernel is a bit different than most open source projects since it
controls HW and lots of buggy BIOS flavors.

(1) I'm using bugzilla.kernel.org to track tulip driver bugs. Not everyone is doing that. It's
helped that akpm has (had?) funding (from google?) for someone to help cleanup and poke
maintainers about outstanding bugs. Despite not everyone using it, it's still a better
tracking mechanism than sending an email to lkml. Do both. email to get attention and bugzilla
to track details. But also send bug reports to topic-specific lists since it's more likely
people who care about your HW will notice the report.

(2) Not that I'm aware of. The kernel interacts with HW alot. It's very difficult to emulate
or "mock" that interaction. Not impossible, just hard and the emulation almost never can
capture all the nuances of broken HW (see drivers/net/tg3.c for examples). Secondly, we very
often can only test large subsystems or several subsystems at once. e.g. a file system test
almost always ends up stressing the VM and IO subsystems. Networking stresses DMA and SK buff
allocators. UML and other virtualization of the OS make it possible to test some subsystems
w/o specific HW. However there are smaller pieces of the kernel which can be isolated and
tested: e.g bit ops (i.e. ffs()), resource allocators, etc. It's just a lot of work to
automate the testing of those bits of code. But this is certainly a good area to contribute if
someone wanted to learn how kernel code (doesn't? :)) work.

For testing subsystems, see autotest.kernel.org and http://ltp.sourceforge.net/. autotest is
attempting to find regressions during the development cycle.

Andrew Morton on kernel development

Posted Jun 11, 2008 19:02 UTC (Wed) by nbarriga (guest, #49347) [Link]

It seems that autotest.kernel.org doesn't exist...

Andrew Morton on kernel development

Posted Jun 11, 2008 22:57 UTC (Wed) by erwbgy (subscriber, #4104) [Link]

That should be http://test.kernel.org/ and http://test.kernel.org/autotest for documentation.

Andrew Morton on kernel development

Posted Jun 12, 2008 2:23 UTC (Thu) by grundler (subscriber, #23450) [Link]

Yes - I meant http://test.kernel.org. Sorry about that.

Andrew Morton on kernel development

Posted Jun 11, 2008 20:01 UTC (Wed) by iabervon (subscriber, #722) [Link]

I think there's a substantial difference to the way he phrased the suggestion here from what
I've seen before. People tend to think of a bugfix-only release as one in which the mainline
only merges bugfixes. Simply making that policy would almost certainly lead to no more
bugfixes than usual, and twice as many features hitting the following release window.

On the other hand, if the process were driven from the other end, it might work: spend some
period collecting a lot of unfixed bugs, and saturate developers' development time with them,
and, in the cycle after that, there ought to be a lot of bugfixes and no new features, simply
because all that will have matured at the merge window will be bugfixes.

So, if there were a period where there was a campaign to collect long-standing bugs and
regressions against non-recent versions, with the aim of having all of these get resolved in a
particular future version, as the main goal for that release, I think that would be useful.