From: akpm@linux-foundation.org Date: Tue, 13 May 2008 21:05:50 -0700Andrew, you have to figure out what we're supposed to do here. If I "fold in the patch" to avoid breaking bisection, I have to completely rebase my tree screwing up everyone of my downstream developers. Or is this some patch I'm supposed to remember to fold in several months from now, to some random changeset out of thousands, when the merge window opens? Neither option is tenable, and the headaches of neither are worth it purely for the sake of bisection. My solution to the bisection problem is to wait a day before pushing out usually, it's a best effort thing. I do as many sanity builds as I can, and we also hope that someone during that day might solve the problem independantly and post a fix. That way I can fix it in my tree locally before the tree goes public. And I think this is the most reasonable approach. Once I push something to my public tree, quite frankly, it's the real deal, it's staying there, and it's a part of the permanent record. And therefore, we'll put fixes on top. --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Kamalesh Babulal | [BUILD-FAILURE] 2.6.26-rc8-mm1 - build failure at drivers/char/hvc_rtas.c |
| Luciano Rocha | usb hdd problems with 2.6.27.2 |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Christoph Lameter | Network latency regressions from 2.6.22 to 2.6.29 |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
git: | |
