← Back to team overview

openerp-community-reviewer team mailing list archive

Re: OCB conflict: timesheet timezone vs. new attendances in confirmed timesheet

 

Hello,

>From my point of view, we should stick as much as possible to official
branch.

So as long as the fix of Martin Trigaux works as expected, we should revert
my fix and keep his last work.

I'll check this ASAP.

Cheers,
Yannick


On Fri, Apr 25, 2014 at 9:24 PM, Stefan <stefan@xxxxxxxx> wrote:

> Dear community reviewers,
>
> news from the OCB-replay front here. We have had a couple of trivial
> conflicts recently, caused by OpenERP developers fixing bugs in the 7.0
> branches that are already fixed in OCB but more or less differently
> (sometimes because they were unaware of the community fix, and sometimes
> with good reason). This is signalled by the replay process and at that
> moment we go in and revert the OCB fix in favour of the upstream fix. I
> try to take care and indicate this on the original OCB merge proposal.
>
> Today however, the addons replay process broke on a less trivial
> conflict between
> http://bazaar.launchpad.net/~openerp/openobject-addons/7.0/revision/10015and
> a fix for a totally different problem by Yannick Vaucher:
>
> https://code.launchpad.net/~camptocamp/ocb-addons/7.0-fix-1204224-yvr/+merge/183670
> .
>
> It would seem wise to ask the original submitter of the conflicting OCB
> revision to resolve this conflict himself by proposing a branch that
> includes lp:openobject-addons/7.0 up until revision 10015 into
> ocb-addons. Yannick, would that be possible? (unless someone else
> volunteers)
>
> As for the replay process, there are basically two options here and I
> need a vote on this from you
>
> 1. revert the conflicting ocb revision in lp:ocb-addons ASAP to restart
> the replay process, or
> 2. do nothing and keep the replay process stalled at the current
> revision until the conflict has been resolved, proposed and approved
>
> For me, it depends on the time that it would take Yannick or someone
> else to submit a solution. I'd prefer to shorttrack this and hold off
> new bugfixes in upstream OpenERP for a short period of time rather than
> cause a regression but I don't know if that is possible.
>
> Note that the choice we make slightly affects the approach to fix the
> conflict: in the first case, the original bugfix needs to be reapplied
> because the bzr revision containing it is already included in OCB but
> its changes reverted. In the second case, it suffices to merge
> lp:openobject-addons/7.0 -r 10015 into a branch of ocb-addons, which
> will reveal the conflict.
>
> Hoping to hear from you.
>
> Cheers,
> Stefan.
>
> --
> Therp - Maatwerk in open ontwikkeling
>
> Stefan Rijnhart - Ontwerp en implementatie
>
> mail: stefan@xxxxxxxx
> tel: +31 (0) 614478606
> web: http://therp.nl
>
>
> --
> Mailing list: https://launchpad.net/~openerp-community-reviewer
> Post to     : openerp-community-reviewer@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community-reviewer
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Yannick Vaucher
Business Solutions Software Developer

Camptocamp SA
PSE A, CH-1015 Lausanne
Phone: +41 21 619 10 30
Office: +41 21 619 10 10
http://www.camptocamp.com/

Follow ups

References