hi tommaso given some issues faced with backports in the past, i would wish this to be persistent and not just time boxed.
kind regards angela On 14/03/17 12:07, "Tommaso Teofili" <tommaso.teof...@gmail.com> 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 ><mdue...@apache.org> >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/e5e71b61de9612d7cac195cbe948e8bdca58 >>ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E >>
