Linus Torvalds wrote:linux-next is _supposed_ to be solely the stuff that is ready to be sent to you upon window-open. The only thing that isn't reliable are the commit ids -- and that's at the request of a large majority of maintainers, who noted to Stephen R that the branch he was pulling from them might get rebased -- thus necessitating the daily tree regeneration. So, I think a 'next' branch from you would open cans o worms: - one more tree to test, and judging from linux-next and -mm it's tough to get developers to test more than just upstream - is the value of holy penguin pee great enough to overcome this another-tree-to-test obstacle? - opens all the debates about running parallel branches, such as, would it be better to /branch/ for 2.6.X-rc, and then keep going full steam on the trunk? After all, the primary logic behind 2.6.X-rc is to only take bug fixes, theoretically focusing developers more on that task. But now we are slowly undoing that logic, or at least openly admitting that has been the reality all along. Jeff --
| Alan | Re: [RFC] Heads up on sys_fallocate() |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Paul Mundt | Re: 2.6.22-rc4-mm2 |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: [GIT]: Networking |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
