>From a developer pov I actually don't like merge commits, the are a pita. Where merges are nice is for the tree maintainers as they don't have to deal with the individual commit series but track/deal with merge entries. The deeper you go into tree maintainer hiearchy the more important it becomes (basically it is what lets linus scale).
As for how much longer considering bisect keeps lying and saying there is about 12 steps left but the number of commits is not being halved, I have no idea how many more it will go through. This has been the longest most painful bisect I have ever done, not only from the pov of number of builds we have cycled through, but also the number of build failures. For almost every build there have been multiple commits that fail to build. This just shouldn't be happening with upstream commits. So I took a guess and moved the head manually for this next one, bisect is reporting 706 commits (~10 steps), and if bisect only steps a little, I'll do it again. next test kernel http://people.canonical.com/~jj/linux-image-2.6.39-2-generic_2.6.39-2.7~lp793437.36_amd64.deb based on 62bdb288bf464862a2801b2e53aadc6c4d100fab -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/793437 Title: Unusable Slowness In 2.6.38-8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/793437/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
