Cc: Jeff Garzik <jeff@...>, Paul Mackerras <paulus@...>, Rafael J. Wysocki <rjw@...>, David Miller <davem@...>, <linux-kernel@...>, Andrew Morton <akpm@...>, Jiri Slaby <jirislaby@...>
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:
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.
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
--
