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 >
