User: Password:
|
|
Subscribe / Log in / New account

The value of release bureaucracy

The value of release bureaucracy

Posted Apr 20, 2012 15:03 UTC (Fri) by dlang (subscriber, #313)
In reply to: The value of release bureaucracy by slashdot
Parent article: The value of release bureaucracy

the stable tree is a branch from mainline.

The intent is that it contains a subset of the changes that have gone into mainline since the branch point (on the theory that adding the other changes may cause regressions)

the problem is that if changes are made to the stable branch that do not go into the mainline, then there is a real probability that the next stable branch will be missing the fix and users will break yet again

if the fix goes into 3.3.2, but not 3.4-mainline, then when the 3.4.0 mainline release (and the 3.4.1 stable release) come out then the fix will not be there and users will break yet again and justifiably scream about the incompetent kernel developers who can't track fixes.

this is the reason behind the policy that _nothing_ goes into stable unless it is already accepted into the mainline.

This isn't a high bar to reach, if you have a fix, send it to Linus for acceptance and cc the stable tree and it will get into both, but if you _only_ send it to stable, it won't get in.


(Log in to post comments)

The value of release bureaucracy

Posted Apr 20, 2012 17:25 UTC (Fri) by slashdot (guest, #22014) [Link]

Yeah, but doesn't merging stable into mainline (either via git merge, or by manually checking if any commit is missing in mainline) achieve the same thing, and allow stable to immediately include fixes?

The value of release bureaucracy

Posted Apr 20, 2012 17:26 UTC (Fri) by dlang (subscriber, #313) [Link]

no, because the fix in stable does not necessarily work with the other changes that have happened in the mainline.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds