Linus Torvalds writes:Having things ready by the time the merge window opens is difficult when you don't know when the merge window is going to open. OK, after you release a -rc6 or -rc7, we know it's close, but it could still be three weeks off at that point. Or it could be tomorrow. That's mitigated at the moment by having the merge window be two weeks long. So if you open the merge window at a point where I, or someone downstream of me, thought we still had two weeks to go, we can hurry up and try to get stuff finished within the first week and still get it merged. But if you made a really hard and fast rule that only stuff that is in linux-next at the point where the merge window opens can be merged, AND the point at which the merge window opens is unknown and unpredictable within a period of about 4 weeks, then that makes it really tough for those of us downstream of you to plan our work. By the way, if you do want to make that rule, then there's a really easy way to do it - just pull linux-next, and make that one pull be the entire merge window. :) But please give us at least a week's notice that you're going to do that. Paul. --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Arjan van de Ven | [Announce] Development release 0.1 of the LatencyTOP tool |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 020/196] IDE: Convert from class_device to device for ide-tape |
git: | |
| Tantilov, Emil S | RE: [PATCH] net: sk_alloc() should not blindly overwrite memory |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
