Weekly Edition
Return to the Kernel page
| |||||||||||||
|
| |||||||||||||
The -mm of the minute tree
In the introduction to 2.6.24-rc2-mm1 (the
first -mm tree in some time), Andrew Morton noted that some people want
something even more bleeding-edge. So he has created the -mm of the minute tree,
which is updated a few times every day. "I will attempt to ensure
that the patches in there actually apply, but they sure as heck won't all
compile and run." The tree is exported as a patch series, so Quilt
is needed to turn it into something which can be compiled. Have fun.
(Log in to post comments)
The -mm of the minute tree Posted Nov 14, 2007 18:47 UTC (Wed) by MighMoS (guest, #37204) [Link] This from the person who wanted less bugs? Interesting. Wouldn't it be more useful to put out an -mm (light) tree, which has patches that are pretty stable, but need a final checking out?
The -mm of the minute tree Posted Nov 14, 2007 19:20 UTC (Wed) by i3839 (subscriber, #31386) [Link] A way to get less bugs is by detecting them early. Having an unstable branch in the form of -mm means that mainline doesn't become that testing branch. At least that's the idea.
The -mm of the minute tree Posted Nov 15, 2007 14:57 UTC (Thu) by dan_linder (guest, #88) [Link] Didn't someone come up with a distributed system that would take an entire kernel tree and step through many combinations of the configuration options and run the full kernel compile, tracking which compiles worked and which died? My home systems sits idle from 8-5 (with the exception of some of the Folding@Home and other related distributed tools). If someone could point us toward this tool, I could feel like I was assisting the Kernel project in some small way. :-) Dan
The -mm of the minute tree Posted Nov 15, 2007 16:49 UTC (Thu) by i3839 (subscriber, #31386) [Link] I think I know what you mean. There were those nice red/green matrix for which kernel version worked (compiled/booted) and which not, per architecture, right? Or was that something else? I don't remember who that person was, Dave Jones perhaps? There are a few people with good testing environments/compile clusters, but I'm not aware of anyone releasing their hacked up test scripts. As for generating a random config, you can do "make randconfig" nowaday. So it's rather easy to automate a random config, install, reboot, and test report. You can also run some benchmarks/test to check for regressions with your normal config. http://ltp.sourceforge.net seems like a good start. If you want to do something more useful, but less automated, you could try out different patches to see if they work or not (personally I'm mostly interested in VM patches, but whatever you fancy).
The -mm of the minute tree Posted Nov 15, 2007 18:09 UTC (Thu) by i3839 (subscriber, #31386) [Link] Mingo seems to be the one (or one of them): http://lkml.org/lkml/2007/11/15/202
The -mm of the minute tree Posted Nov 15, 2007 18:12 UTC (Thu) by i3839 (subscriber, #31386) [Link] Oh dear, what an embarrassing typo, noticed it a split second too late. If I'm lucky it's his LWN account name, and I've some sort of sleazy excuse. Now let's hope no one notices it... ;-)
The -mm of the minute tree Posted Nov 15, 2007 19:18 UTC (Thu) by flewellyn (subscriber, #5047) [Link] It is his LWN account name, actually. I didn't notice it as a typo until you pointed it out, for that reason.
The -mm of the minute tree Posted Nov 16, 2007 21:19 UTC (Fri) by nix (subscriber, #2304) [Link] It's also his email address, so in a sense it's not wrong at all :)
The -mm of the minute tree Posted Nov 14, 2007 19:44 UTC (Wed) by iabervon (subscriber, #722) [Link] The idea is that bugs get filtered out at various stages: when people test mainline before it is released, when people test -mm before stuff goes into mainline, when he tests -mm before releasing it, when the authors test their patches before sending them to him. While he wants all of these filters to be as effective as possible, the "when he tests -mm before releasing it" part has been getting clogged enough that he's personally overworked. So he's adding the ability for more people to test in that stage, which also means that there's more visibility to bugs that don't get filtered out by their authors, with the goal of authors doing more testing at that stage. Furthermore, there's currently the issue that, if he misses a bug in his testing that prevents people from being able to test that version, it's relatively slow to get back to a testable state, which reduces the amount of testing that gets done during -mm and means that fewer bugs are filtered in this stage. Having a bunch of people try compiling it (at least) with different configurations on a continuous basis, with the series file so they can blame the right patch, means that there's a larger chance that a -mm tester has something to test at any given moment.
The -mm of the minute tree Posted Nov 15, 2007 13:46 UTC (Thu) by wilreichert (subscriber, #17680) [Link] What was his reason for not keeping a git tree? I recall seeing Andrew comment on that at some point somewhere.
The -mm of the minute tree Posted Nov 15, 2007 20:03 UTC (Thu) by joern (subscriber, #22392) [Link] Git is a real pain for the kind of process Andrew has. Every cycle he receives a large number of patches, drops some of them again, merges some in the next merge window, some later, some never,... Git is great if everything you add to it remains unchanged and makes it to Linus. But when sorting out and deciding what to merge, quilt and similar tools are much nicer.
The -mm of the minute tree Posted Nov 25, 2007 9:22 UTC (Sun) by jd (guest, #26381) [Link] Good luck to him. I could never handle even a fraction of the patches over much larger timeframes, due to the horrible conflicts between them. He is strong in the Force indeed.For those who want fewer bugs, I agree that we need to bug-stomp, but name how many QA people have got involved in kernel testing? The testing framework in the kernel, as it stands, is limited at best, which makes testing complex at best. (No, GDB via the kernel is not much use for this kind of thing.) There are many ways to deal with bugs, but as far as I can tell, most of the things being tried include complaining about them, not fixing them - or, indeed, finding them. The kernel has been doing poorly in regression tests for some time, but let's be honest here. How many of us have submitted a single patch to fix any of them? Hey, I'll be honest here, I haven't, and that is something I have a moral obligation to fix if I can. I've used the Linux kernel, so I owe the kernel developers. I have no business trying to escape that obligation. But neither do any of the other Linux users out there.
|
|
||||||||||||