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 increase visibility of the backports and
ensure they are eventually reviewed.
{quote}
And later on:
{quote}
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.
{quote}
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 failure after the fact -> revert again
With 3 we don't limit ourselves to perform the review in a fix time frame,
which might not be feasible.
Wdyt?
Kind regards
Angela
On 16/03/17 09:53, "Davide Giannella" <[email protected]> wrote:
>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 do for releases. This is to prevent a backport to be
>stalling for too long. We may even define a vote policy like for
>releases but to be taken on the issue itself rather than here in the list.
>
>Davide
>
>
