[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable
tony.luck at intel.com
Tue Jun 19 19:29:41 UTC 2012
> The problem is, we do not enforce any of this. It's all been more of a
> "please do it this way". The only one that could possible enforce it is
> Linus himself. He could say, "I'm not accepting this unless it was in
> linux-next for a full release".
A full release seems rather extreme ... but there might be more support
for "a couple of weeks".
E.g. code going into linux-next up until "-rc5"[*] is announced is a candidate
for inclusion in the 3.x merge window. People can (and should) keep supplying
linux-next with new things beyond that point ... but they will be candidates for
This could also be the rebase deadline ... trees feeding linux-next should
be *encouraged* to rebase (to add more "Tested-by", fix speeling mistales,
squeeze out superfluous commits, combine pointlessly split commits, improve
commit message text, add Cc: stable) ... all the stuff that will make the
history of mainline more readable and useful ... but leaving enough time
that Linus will feel that the patches have had testing in the form and
environment that he is being asked to pull.
Possible upside of having a defined point would be more people focusing
testing on the next-YYYYMMDD release that comes out at -rc5 - so we will
find and fix problems that would otherwise show up in the merge window.
[*] Arbitrary point ... assumes that -rc6 is the final release candidate
with release one week after that.
More information about the Ksummit-2012-discuss