Re: Policy for reverting changes

From: Kinkie <gkinkie_at_gmail.com>
Date: Fri, 17 Aug 2012 19:59:18 +0200

On Fri, Aug 17, 2012 at 6:49 PM, Henrik Nordström
<henrik_at_henriknordstrom.net> wrote:
> tor 2012-08-16 klockan 23:11 -0600 skrev Alex Rousskov:
>
>> I am not annoyed at the failures -- we all commit broken code once in a
>> while, and there is currently no good way to prevent even simple build
>> failures.
>
> Yes..
>
>> I am somewhat annoyed that some failures result in commit reversal (with
>> unusable or contradictory information as to the reason for the reversal)
>> while others are not (even after detailed reasons have been provided),
>
> Reversals are not routine. There is no automatic reversal, instead it is
> up to each and everyone to decide on when reversal is appropriate and
> when not.
>
> Ok, here is a proposal on a little policy on the topic on how to handle
> others bad commits:
>
> trunk:
>
> 1. If possible, fix it.
> 2. If not, nag the person who committed the problematic code.
> 3a. If no response in 24 hours and it's blocking other things (including
> test farm builds) then revert the commit with a notice to squid-dev.
> 3b. If still broken after 7 days of discussion and attempts to fix then
> revert the change.
> 4. Let it mature in a development branch, and submit for merge again
> when the issues have been resolved.

Sounds very reasonable to me.
In this case, I took path 1, complicated by the fact that the breakage
wasn't visible to me.
(the patchlet I sent earlier on is confirmed as good to fix the last
remaining issues, including making the breakage visible in
layer-02-maximus.)

> It's a real pity bzr do not have a "unmerge" operation. Currently
> reversals are quite intrusive and may merge to the branch where the
> feature was developed erasing it from there as well.

Have you considered "bzr uncommit"?

Uncommitting the last revision(s) it's very easy:
bzr uncommit -r revno-to-return-to, bzr revert

But a process such as the follwoing should do the trick to uncommit a
merge which has occurred at revision N:

bzr uncommit -r N+1
bzr shelve --all
bzr uncommit
bzr revert
bzr unshelve --apply
bzr commit

Note: this doesn't take into account commit messages, conflicts etc.
Robert can certainly comment on the feasibility of the approach, or
any better approaches.

-- 
    /kinkie
Received on Fri Aug 17 2012 - 17:59:24 MDT

This archive was generated by hypermail 2.2.0 : Sat Aug 18 2012 - 12:00:07 MDT