Hi, Mathieu Simon wrote:
> But I'm not fully sure about your answer, if I understood you correctly > this means > cherry-picking every single related patch from 3.4-rcX to 3.2.(12) let's > say from gregkh. - Right? I suppose my answer was less helpful than it could have been. :) Patches in the Debian kernel repository look like this: http://svn.debian.org/viewvc/kernel/dists/sid/linux-2.6/debian/patches/ The baseline for the current sid kernel is gregkh's 3.2.y kernel. When patches meet the criteria described in Documentation/stable_kernel_rules.txt, we can get them applied to 3.2.y and share their maintenance with others (no patch in the kernel repository needed in that case). For miscellaneous fixes not in the -stable tree, all that is needed is a list of commit ids corresponding to patches' appearance in linus's "master" or some tree that feeds into it. Driver backports are also often treated this way, and it's probably the right thing to do for your case. I do not think one big patch is ever acceptable for this, since it would make it way too hard to back out one patch while debugging. However, in theory it is even better (maybe "the kernel team is happiest" was a stretch) if a maintained version of the driver backport can be shared between distros and others using the same basic kernel/driver version combination. This is roughly speaking the way graphics drivers are maintained in squeeze: there is a "linux-2.6.32.y-drm33.z" tree that keeps track of fixes that were discovered to keep the graphics drivers from Linux 2.6.33.y working well against a 2.6.32.y kernel. That is fussy work and a long-term commitment, so it was probably not the best answer to "what does Debian prefer". Upshot: if you send a list of relevant commit ids for commits that are not in 3.2.y, that's a good start, and we can try applying them and go from there. (If it's just the list output by git log --no-merges --oneline v3.2..origin/master \ -- drivers/hv drivers/staging/hv then the kernel team could just use that, but I think you mentioned needing a few more.) Thanks much and sorry for the lack of clarity. Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120402003644.GA29984@burratino
