openerp-community team mailing list archive

[Nicolas Bessi <nicolas.bessi@xxxxxxxxxxxxxx>]

Hello,

I agree with the fact that OCB merging and reviewing must be the less painful as possible and having simple process is mandatory.

The flexibility of OCB and a certain form of freedom driven by community is also something to preserve.

Maybe community (or OCA) can provide his own runbot infrastructure in a later stage.

Anyway any change to OCB or official branches are always sensible topics as they impact a lot of people work. 
I'm glad to see that it is actively discussed on community mailing and solution will not be found the rogue way but acknowledged by community.

Regards 

Nicolas




Olivier Dony <odo@xxxxxxxxxxx> a écrit :
>On 2013-10-25 16:44, Stefan wrote:
>> On 10/25/2013 04:21 PM, Olivier Dony wrote:
>>>
>>> Only a few obstacles remain before this can become a reality:
>>> 1/ The OCB branches would need to be relocated under the official
>>> projects
>>> 2/ The OCB branch management process needs to be adapted accordingly
>>> 3/ Compliance with the OpenERP stable policy [2] should be added to
>>> the review checklist for OCB branches, and the current branches
>>> reviewed in this light
>>> 4/ (Option) In order to allow for some degree of non-compliant
>>> changes, an "experimental" version of the OCB branches could be
>>> forked. It would not be recommended for production and not merged
>back
>>> into the official distribution.
>>>
>>> Stefan, does this accurately describe the options we discussed?
>>>
>>
>> Thanks Olivier, for highlighting your intentions in this direction
>again.
>>
>> My personal gripe is with [3]. I think having an 'unstable' series
>that
>> does allow the occasional new field to percolate through is a major
>> attraction to OCB. It must be the reason that I remember our
>> conversation at the community days slightly differently: keep the OCB
>> branch in its current form with its current policy, but using
>technical
>> means to mark merged changes that conform to the OpenERP stable
>policy
>> so that you can easily feed back bugfixes from OCB to the official
>> series. We have not yet had the chance to work this out.
>
>I understand that you may see non-compliant changes as a desirable
>feature of 
>the OCB branches. And that does not preclude having them in the
>official 
>projects and tracking them in runbot as well, of course!
>
>Unfortunately I would have the same problem as Lionel if we can't
>simply merge 
>the branches after reviewing the diff. If the process becomes too 
>time-consuming or technically impractical for us we won't be able to
>dedicate 
>resources to do it. It also seems that cherry-picking commits will
>increase the 
>chance of conflicts when you auto-merge those commits back into the OCB
>
>branches. That's one of the reasons why I thought we had discussed the
>creation 
>of 2 versions of the OCB branches:
>- one stable version very close to the official branches (i.e. a few
>commits ahead)
>- one experimental version with extra commits for technical people who
>know 
>exactly what they're doing and don't mind diverging from the official
>version.
>
>Note that you could perhaps modify your OCB scripts to automatically
>maintain 
>the "stable OCB branch" based on the "experimental" one with some
>commit tags, 
>but that may be overkill.
>
>On a related subject, I was also wondering about the future of those 
>divergences from the official version once a new OpenERP release is
>out. Based 
>on OpenERP's architecture I imagine the easiest would be to move them
>to 
>appropriate community modules?
>
>
>> As for hosting the series branches under openobject-addons, that
>would
>> be great. I'll gladly give up the separate projects for the ease of
>> having to prepare only a single branch and MP for each fix.
>
>Great!
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openerp-community
>Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openerp-community
>More help   : https://help.launchpad.net/ListHelp