https://bugs.freedesktop.org/show_bug.cgi?id=33867 --- Comment #4 from Dave Witbrodt <dawitbro@xxxxxxxxxxxxx> 2011-02-05 10:58:38 PST --- Part 2: pre-rc1 and early rc* kernels suck In Comment 2 above, I built 4 kernels directly from drm-fixes. I was guided in those choices by the results of bisecting the kernel I had made from individual cherry-picks, believing that the order in which commits appear in 'git log' is the same as the order used during 'git bisect'. (That assumption turns out to have been wrong.) Anyway, I immediately ran into problems bisecting because the kernels you get from drm-fixes at specific SHA1 commits are in widely-varying states of usability. (That's why I was trying to cherry-pick stuff onto a stable release of 2.6.37 in the first place!). Based on my findings with the 4 kernels in Comment 2, I bisected this way: git-bisect start 1e644d6d 147666fb There were 5000+ commits between those 2, and the very first commit chosen for me in between these 2 was something from the post-2.6.37 merge window: that kernel would just hang during boot. SUGGESTION: this made me wish there was a better way to test new DRM code. For example, make it possible to test against kernels where other parts of the kernel are likely to be in good shape. Wouldn't it be relatively easy to either: A) have an additional git tree, based on the last stable kernel release, with only new DRM-related patches (and no explosive merge window or rc* detritus)? or B) provide a series of patches so that people wanting to help debug this stuff can have kernels that are fairly stable except for the new experimental code being tested? I love git, but this aspect -- using in-flux developer trees for bisecting -- is very bad for user testing. An "end-user-bisect" tree, rebased at each stable kernel release, containing only new DRM-related code patches, might be a great improvement over the current situation. (Unless having end users running 'git bisect', and spamming the f.d.o. Bugzilla, is something you devs are intentionally trying to avoid....) I know this would mean even more burden on already overtaxed devs, but it's probably something that could be automated if devs who submit patches to D. Airlie bought into supporting it. Making a kernel from individual cherry-picks after gazing at 'git log' changes since the last stable release is much more difficult, but it's something I've been doing for the past year... I'm just a noob! :-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
