Le 25/10/2013 16:44, Stefan a écrit :
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.
From the point of view of a modest contributor shop like ours, it's be
too much work to use the OCB branches this way.
Indicating policy-complience of each commit means I have to cherry pick
the commits I want to merge into my own branches. I can't afford that.
And I really don't think this is the way bzr is supposed to be used.
It'd be much easier for everyone if you maintain 2 sets of branches :
- a community-maintained branch complying with the bugfix-only policy,
that OpenERP can merge into the core
- the "OCB" branches with the new fields (after all the B means
backport!), based on the bugfix-branch.
Lionel Sausin.
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : openerp-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
