Messages in this thread | | | Subject | Re: Slow DOWN, please!!! | From | Krzysztof Halasa <> | Date | Sun, 04 May 2008 15:47:25 +0200 |
| |
Personally I think the current process works reasonably well, though as we should always try to improve it further...
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 1 May 2008, Jeff Garzik wrote: >> - 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?
I think you could branch at ~ rc3 (strictly critical fixes only from this point). This way 'next' wouldn't be low-maintenance but the release branch would be.
I.e., the merge window would open at ~ rc3. At 'final', the merge window would probably be already closed :-)
Something like: - 2.6.26-rc3: 2.6.27 merge window opens, 2.6.26 - fixes only - 1 week later: no core changes for 2.6.27 except fixes (drivers only?)
2.6.26* would receive backports from 2.6.27 (cherry-picking? applying on 2.6.26 and merging?).
The "no open regressions" rule would make sense certainly - unless in a specific case agreed otherwise.
Perhaps if needed you could let other people do the final release ("stable" extension) and concentrate on the trunk.
> If I'd have both a 'next' branch _and_ a full 2-week merge window, there's > no upside.
Shorter cycle is the big upside.
Perhaps we could start branching later at first - say at 2.6.26-rc5, and see how does it work. -- Krzysztof Halasa
| |