385
385
Reviewing for the Stable Branch
386
386
*******************************
388
These are guidelines and can be interpreted case-by-case.
388
390
* All changes to the stable branch should fix a bug, even if you would not
389
391
normally file a bug for the change. The bug description should if at
390
392
all possible explain how to manually verify the bug in a way that will
391
393
fail before and pass after the change. (These are requirements for the
394
* The change should be reasonably small and conservative. Be extra
395
careful of things that could break on other platforms or locales.
396
* The change should be reasonably small and conservative.
398
* Remember that the patch will be read during the SRU
399
process and so keeping the patch small is useful even beyond keeping the
400
logical changes small. Avoid doing mechanical bulk changes on the
403
* Use particular care for things that may behave differently across
404
platforms, encodings or locales. It's harder to thoroughly test these
405
things before a release.
407
* Generally speaking, just cleaning things up is not a sufficient reason
408
to make changes to the stable branch. It has to actually fix a bug.
410
* Changes to the stable branch should include tests as usual.
412
* Don't change or remove existing APIs that might be used by plugins, even
413
if they are underscore-prefixed. Adding APIs that are also being added
414
to the trunk branch may make sense.
416
* Keeping consistency with trunk is useful, but less important than
417
keeping the stable branch stable.
397
419
* (more items welcome)
402
#. List thread "[rfc] six-month stable release cycles", July 2009.
424
#. List thread "`[rfc] six-month stable release cycles`__", July 2009.
426
.. __: https://lists.ubuntu.com/archives/bazaar/2009q3/060882.html
405
429
vim: filetype=rst textwidth=74 ai shiftwidth=4
added
removed
doc/developers/cycle.txt
