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.
-- /kinkieReceived 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