openerp-community team mailing list archive

[Stefan Rijnhart <stefan@xxxxxxxx>]

On 10/28/2013 08:30 PM, Olivier Dony wrote:
> So it's very simple: if the OCB contributors find it useful to have a 
> faster commit path to the stable branches, then they might find that 
> respecting the stable policy somehow is worth it. It's an easy way to 
> give more power to the community.

Hi Olivier,

you do make it sound simple but like I asked Fabien earlier on in this 
thread, would you be able to take all of the revisions if we kept the 
small amount of schema-changing ones out? The answer of course is very 
likely to be no, at least not all of them. That means that a two way 
granularity on branch level (splitting up schema changers from the rest) 
may good enough to base a semi-automated feedback process on.

Or what would be the process if you disagreed with a number of 
ocb-specific changes that you encounter? Would we be required to 
transfer them to the branch of rejects, then try again? It seems very 
cumbersome for both sides.

Back at the community days I was thinking maybe we can come up with 
something nifty and create a crazy bzr plugin to create 
cryptographically signed revision taglets combined with replay so that 
you could have a 'one bzr command' feedback proposal any time and if you 
disagreed on anything either side could update the tags. But I'm not 
sure if it's going to be less of a hassle than for you to simply 
periodically look at what has been merged recently in OCB on Launchpad...

Sorry to sound a bit grumpy what with all your good spirits and 
initiative in this matter! I am genuinly interested in what you, and 
others, think of these obstacles.

> So how do you plan to handle this? What will become of your 7.0 
> divergences once 8.0 is released?

We'll have to see what the ratio of divergence is, and then decide if we 
want to split off some things that did not make it passed you guys in 
separate modules if possible, and other things we might just try to get 
passed you again ;-)

Cheers,
Stefan.