documentation unless there are further objections.
Done http://svn.apache.org/viewvc?rev=1792601=rev
Michael
Michael
On 14.03.17 11:59, Michael Dürig wrote:
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 mo
On 10/04/2017 16:59, Michael Dürig wrote:
> "Back ports bear a certain risk of introducing regressions to
> otherwise stable branches. Each back ported change should be carefully
> evaluated for its potential impact, risk and possible mitigations. It
> is the responsibility of each committer to
ichael
On 14.03.17 11:59, Michael Dürig wrote:
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 ca
On 16/03/2017 09:31, Michael Dürig wrote:
>>
>> With 3 we don't limit ourselves to perform the review in a fix time
>> frame,
>> which might not be feasible.
>
> That's exactly what I had in mind!
So we're still speaking of CTR rather than RTC.
Good for me. Doesn't really change anything on the
My interpretation of this is as follows:
1. I send out a notification before merging changes
2a. I think review should pass anyway -> go ahead and merge
2b. Otherwise: give others some time to look at it before merging,
depending on complexity, availability etc.
3. Optional: In case of review
Hi Davide
>From what I understood, Michaels proposal would not cause a stalling
backport:
{quote}
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
On 14/03/2017 10:59, Michael Dürig wrote:
>
> 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.
+1 if we time box it for each backport. For example 3 days or whatever.
Something like we
I don't think this works well:
On 14.03.17 14:04, Julian Reschke wrote:
Let me suggest something else:
a) follow commit emails,
As outlined in my previous mail this distributes the effort of figuring
out the particulars of a backport to every committer where it would be
less effort to
;>
>>> 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
>&
On 2017-03-14 13:46, Michael Dürig wrote:
...
The code review is something we should be doing anyway. The only added
overhead here is the extra email asking for review. This is a bit of
extra work for the person doing the backport but saves a couple of
others time figuring out what a commit is
On 14.03.17 12:54, Julian Reschke wrote:
On 2017-03-14 11:59, Michael Dürig wrote:
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
On 2017-03-14 12:54, Julian Reschke wrote:
On 2017-03-14 11:59, Michael Dürig wrote:
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
2017-03-14 11:59 GMT+01:00 Michael Dürig <mdue...@apache.org>:
>
> 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
On 2017-03-14 11:59, Michael Dürig wrote:
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
rts 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 f
>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
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 her
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 defin
sounds like a plan
angela
On 14/03/17 11:59, "Michael Dürig" <mdue...@apache.org> wrote:
>
>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 tha
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
20 matches
Mail list logo
