On 09/27/2010 09:17 AM, Boaz Harrosh wrote: [snip /] > > <RANT A HEAD CAN BE IGNORED> > > It has become extremely hard to bisect a simple problem in latest Kernels! > > Most mainline merges during a merge window are based on an rc1 of the previous > Kernel. In the last 5 Kernels there was a 90% chance of a BAD bug in systems > I use, at rc1. If a bug is found that needs bisecting. The other bugs creep > up during bisect and mask out the possibility to bisect.
I had similar problems when bisecting the recent USB HID regression. Once I realized that "bisect skip" kept dropping me into a rats nest, I guessed on -rc2 and was able to proceed from there. ... > In short I wish at some 2.6.XX-rc[45] of every Kernel cycle. Maintainers > would rebase their next's tree of [XX+1] to a some what more stable rc. > Sure re-run all the tests. They still have time for the new tree in next > to be tested and verified before the next merge window. > (Hell one of my bisect points took me as back as 2.6.34) > > Please remind me why maintainers should not rebase their trees once > committed, to the point that they don't rebase even for buggy patches > that are already in next, and apply fix patches, all within the same > merge window. The same is also done with merge conflicts with the > rc-cycle of their own code, instead of rebasing. > > So in short this is a call for, possibly, cleaner History in main Kernel. > Please remind me why re-writing history is a bad thing. I can't comment on whether rebasing is reasonable at that level, but I was wondering if it made sense to teach git bisect to automatically cherry-pick known regression fixes. If I recall correctly, someone once suggested a history tag of the form "Fixes: <git-commit-id>". By itself, that's probably not sufficient, as I'm sure some relevant commits would get through without that tag. A separate index file containing pairs of commit-ids could supplement the main history. If that sounds like a reasonable approach, I'm willing to take a stab at implementing it. (Unless someone smarter than me beats me to it, of course.) Phil ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
