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.