I would be in favour to generally apply this policy for all branches as
with the number of branches we have now it is too easy to miss something
by just following @commits.
Michael
On 14.03.17 12:07, Tommaso Teofili wrote:
I have one concern: is such a backport policy meant to be time boxed (e.g.
keep it for first N 1.6.x releases)?
I am asking this because I'm wondering if we want to establish this policy
for all backports (1.4, 1.2, 1.0 branches too), or alternatively we aim to
be a bit conservative in the first months of a 1.x release and move back to
a less strict merge policy for backports afterwards.
Regards,
Tommaso
Il giorno mar 14 mar 2017 alle ore 11:59 Michael Dürig <[email protected]>
ha scritto:
Hi,
Following up on Davide's release plan for Oak 1.6 [1] we should define a
merge policy for the 1.6 branch. I would suggest to be a bit more
conservative here than we have been in the past and ask for reviews of
backports. That is, announce candidates on @oak-dev mentioning the issue
reference, potential risks, mitigations, etc. I don't think we need to
block the actual backport being performed on the outcome of the review
as in the worst case changes can always be reverted. The main aim of the
announcement should be to increase visibility of the backports and
ensure they are eventually reviewed.
In short, announce your backport on @oak-dev and ask for review. If
confident enough that the review will pass anyway, go ahead but be
prepared to revert.
I think this is what we informally did so far already but wanted to
state this a bit more explicitly.
WDYT?
Michael
[1]
https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E
