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 : [email protected]
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
