On Friday 18 November 2005 01:51, Blaisorblade wrote: > On Friday 18 November 2005 08:17, Rob Landley wrote: > > On Friday 18 November 2005 01:08, Blaisorblade wrote: > > > On Wednesday 16 November 2005 14:36, Rob Landley wrote: > > > > Linus said this: > > Btw, where does this quote come from?
Linux-kernel, last wednesday. http://seclists.org/lists/linux-kernel/2005/Nov/3391.html > > > > > I think one reason -mm has worked so damn well (apart from you > > > > > being "The Calmest Man on Earth"(tm)) is because it's essentially > > > > > been that buffer for anything non-trivial. Sometimes the "n+2" has > > > > > been a lot more than "n+2" in fact, and that's often good. > > > > > > > > > > (And at the same time, -mm has enough visibility that it doesn't > > > > > drive developers crazy even when the "n+2" ends up being "n+5" or > > > > > somethiing). > > I don't quite get this +2/+5 discussion. Context from the rest of the thread, which started here: http://seclists.org/lists/linux-kernel/2005/Nov/3290.html n is release number. It was about the 2 week merge window and the fact that it's a fairly sucky time to do new development. (It's for merging stuff that you already got to work, and then bug fixes.) The -mm tree is for shaking bugs out of stuff that worked for you, but may not get merged into linus's tree immediately. > > > > > I'd _hope_ that the same kind of situation could work for some of > > > > > the majos subsystem git trees too: where the maintainer tree is > > > > > well enough known that it gets sufficient coverage for that area > > > > > that a "+2" approach for merging into the default kernel is > > > > > practical. > > > > > > > > > > I also think it certainly _should_ be possible for the big areas > > > > > that have well-defined target audiences. > > > > > > Definitely Jeff's tree is a first filter for his work, but I've not > > > seen it working a lot as a collector, especially for little fixes - but > > > there it makes sense. > > > > > > I tend to send directly to Andrew and he forwards them to Linus (in > > > many cases so fast that I wonder if they appear in one -mm release), > > > but I currently do not have a public tree. > > > > So there currently _is_ no one UML tree that people interested in the > > most recent UML developments can check out. We basically have to wait > > until it hits mainline. > > Patches go in -mm first. Currently Andrew is often very quick at merging > them. The problem is (as the discussion brought up), Andrew's tree integrates many things. If you want to test _just_ one subsystem, there's usually a tree you can go to to get just -linus plus the new subsystem. > Also, fixups tend to have less needs for testing - and they're often > backported to -bs. "backported"? So is -bs more stable than mainline? I thought it was your development tree... > Also, I don't tend to merge big patches without first checking. Testing -mm (except for fun) doesn't work for me because too much other stuff is in there and if something breaks I don't know what it is. (It's nice to test it and be able to give a thumbs up if it passes. But failure in -mm is not always a useful data point. Certainly not without "ok, -linus plus -uml-current worked, so something else in -mm is breaking UML on x86-64 building under PLD..." > > I'm not applying the other patches at the moment. Right now I'm just > > trying to get Jeff's tree to build for me. > > Which means applying your own fixups. When absolutely necessary, yes. In theory Jeff's tree works for Jeff so i'm trying to get it to work for me _without_ fixing it myself. (Instead I bug _him_. :) But I'm on a wildly different distro (ubuntu on x86 and PLD on x86-64) and things like maszur's headers or the /lib64 thing I haven't got much choice to patch myself. I try not to _keep_ these patches. You'll notice I post them here in hopes mainline fixes the problem (whether my fix or a different one). > > If I have time tonight I'm > > going to cherry-pick his patch list to see which ones I can get to > > compile, and give him the list of each one that breaks my build (and > > how). > > I suggest quilt exactly because it automates one big task - managing the > stacks of applied and unapplied patches. Will "patch" suggest you which > patch is the top one? What I'm currently doing is: for in in `cat patches/series` do echo $i patch -p1 -i patches/$i done I.E. I'm letting Jeff's "series" indicate which order they should go in. I have nothing against quilt but learning new tools tends to go on my todo list. I go down enough tangential ratholes in an average day as it is. :) > Quilt will. That's why I suggest you to try it. I'm trying very hard to _avoid_ managing my own tree, thanks. If I ever have more than about three patches I'm applying to the tree at once, it's time to either push to get them in mainline or upgrade to a newer version. With the linux kernel I'm applying squashfs (which I would very much like to see in mainline but I seem to have missed that flamewar this time 'round), and one three line removal. The rest is fixups to 2.6.15-rc1 that I hope to see in -rc2 or -rc3. For systems I do lots of new development on, I just use subversion. > > I just > > mentioned that #2 of the recent 4 sent to Andrew broke the build for me, > > but that's not the only breakage I see from Jeff's tree. (I currently > > have access to four different build environments. I was focusing on the > > PLD x86-64 system I'm borrowing, but right now I'm focusing on my ubuntu > > laptop. Then knoppix, and then my Linux From Scratch system with gcc > > 4.0.2 and uClibc... > > > > Expect to be hearing from me a lot. :) > > No problem... just be patient for fixes. I know. :) > And IMHO you shouldn't feel so shy about fixing such compile problems (no > complaining!) I don't expect you to debug the stub problems, but the rest > should be easier to work with. I fixed the header #include problem myself once I understood that Jeff had never used Mazur's headers. He took my patch for that. The /lib64 thing I have no _clue_ how the linker stage of the linux kernel works (it has a linker script to tell ld what to do, and does black magic with elf segments so it can put stuff into the init segment and make a module export list and... Ummm.. Eek.) I know my patch there is wrong (it breaks x86), figuring out what to do about that is a todo item.. The recent breakage I saw with patches.tar was too much damage for Jeff _not_ to have seen, so it was either some kind of compiler version problem where my patches were likely to break _his_ system, or else I didn't understand what was going on. (And #2 was the case: once I found out it was the 0 length files, I could fix that. I didn't expect 0 length files screwing up the #include search paths. The #include search paths are confusing, I'm still a bit fuzzy on the difference between include and include2, actually...) I'm happy to debug stuff myself, when I can. And to submit patches... Rob ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
