openerp-community team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On Mon, Oct 28, 2013 at 9:29 PM, Stefan Rijnhart <stefan@xxxxxxxx> wrote:

> 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.
>>
>>
> 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.
>

It is simple and exactly the same as for regular merge proposals. And
indeed it's not just about db schema changes, it's also API signatures,
design decisions, etc. [1] We'll review the commits and fix those that need
fixing. If the corresponding bug reports are valid, we'll do what it takes
to get the bug fixed properly and according to the policy before merging.

The only kind of patches that we would have to plainly reject would be new
features or wishlists, just like we would reject such MPs in stable.
Non-compliant changes would be replaced by more suitable ones if they were
intended to fix valid bugs.



> 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...
>

Oh, I see... Indeed that sounds like a bit complicated to setup, and it's
not clear to me how you could then re-merge the replayed (aka
cherry-picked) stuff back into OCB later.
We could also look at what has been merged recently in OCB, but I don't see
what the benefit would be for us if there's no chance of making the process
more efficient with time, we could as well work on our own priorities.

My idea back at the community days was more along the lines of ultimately
having OCB as a "bleeding-edge" version of the stable branches, ahead by a
few bugfixes, but carrying a small risk of having a few more glitches to be
ironed out.



>  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 ;-)
>

I can only see the ratio of divergence increasing unless we setup some sort
of convergence system?



[1] The details of the stable policy will be clearly written in the
documentation. The pad I linked earlier contains a draft.