Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


Hi Jan, *,

On Fri, Jul 22, 2016 at 1:22 PM, jan iversen
<jani@documentfoundation.org> wrote:

The ESC discussed when to make large scale changes on master and whether or
not the current policy should be changed.
[…]
Please have a look at:
https://wiki.documentfoundation.org/Development/LargeScaleChanges

And let me know your opinion.

I think it kind of misses the point. It should start with:

Changes that make backporting of other fixes to release branch harder
might be only be merged  *after creation of the x.y.2 release* and
*before branchoff for the next x.y+1 release*.
Why?
the time between the .0 release and the second bugfix release is the
time when most backporting will occur, so this timeframe should be
avoided.

Automatically created changes (changes that  are done by runnning a
prepared script), should be run right before branch-off for the next
x.y+1 cycle. That way it won't interfere with managing the older
branches.

Unsure whether your change falls into that cagegory? Read below....
(then follows description of whether a cosmetic change is one that
hinders backporting, etc)

ciao
Christian

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.