openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello Pedro,

I think the easiest is to merge official v8 into OCB in a v8 OCB serie
branched from the current v7 OCB.

Now, speaking about automation of the thing, we have to take a step back:
for several reasons, OCB and official v7 belong to different projects and
cannot easily be merged due to Launchpad limitation with branches belonging
to different projects. Hence the bzr replay bureaucracy that IMHO is still
frightening many people from submitting their patches to OCB (in fact most
people have just no clue what to do).

Eventually, for v8 we can think about something that would be easier to
manage. I mean we should!

<from __future__ import>
That's why sometimes ago, after I successfully mirrored significant LP
branches to Github using the official git bzr helper (inside recent git
distro), I tried to merge v8 into OCB (in fact saas-2 at the time) and
really did it for server and web here despite not setting up update scripts
from OCB:
https://github.com/akretion/openerp-server/tree/ocb-saas-2
https://github.com/akretion/openerp-web/tree/ocb-saas-2

For server and web repos, the merge was really straightforward.
In fact I had to use a --theirs to handle i18n conflicts and force taking
the official translations instead of digging into manual conflict
resolution.

For addons,
I had around 10 serious non i18n conflicts that I think would take around 4
hours or so (at saas2 time) to be properly resolved and I didn't dig any
further so far.

By doing the thing on Github, I had no issue at all merging OCB and
official despite their different project origin. Git merges them and
compare them just as regular branches and is fast enough to make the thing
productive (unlike bzr).

Now, I understand that eventually we stick to Launchpad for that, but we
have to see if we can afford the bureaucracy of doing so.
Eventually v8 OCB is brought back into the main project so that merge from
official is strightforward again (t also costs when submitting patches),
but if so, merges between v7 OCB and v8 OCB would suck just like today.

So eventually, we could just take that opportunity to start working on
Github and all enjoy great productivity boost while progressively bringing
OCA support for Github too?
IMHO these are currently two important missing pieces for working on Github
and efficiently upstreaming to OpenERP core:

   1. bug cross referencing -> need for tooling, will it be easier than
   current bzr replay stuff? At least it will likely be faster..
   2. no stack branch support in the git bzr remote helper, making it
   impractical to upstream a patch from git to LP when talking about the fat
   monolithic addons repo. Now this is just regular Python, so eventually
   somebody make that wonderful contribution to git python remote helper. More
   specifically, stack branch support should be created around here:
   https://github.com/git/git/blob/master/contrib/remote-helpers/git-remote-bzr#L750
(would
   be need support to be able to clone from an already existing ref tree using
   a stack bzr branch). We would need a script where we could easily and
   quickly replicate an upstream merge proposal to official LP repos.

</from __future__ import>

No matter what the forge/SCM we choose, I can help doing again the merges
for server and addons repo at a given point in time. As for the addons, a
bit of collaboration will be required.


As for automating the process to stay up to date, human work and
responsability is required.

So far Therp maintained OCB and us at Akretion we maintained RS-OCB
(contact model fixed the way the community advocated for) and it was really
human to maintain it (less than a conflict to handle manually per 2 months).

Now merging from fast moving official v8 and v7 OCB is going to be a bit
more involved though.

I think we could have a rotation between several people/company. During a
period somebody is in charge of maintaining the merges, he would have to
fix conflicts, ensure the synchro scripts are running, and call for
community help when tests are falling. Not too hard either when that OCB
branch doesn't claim to bring new feature (other tracking branches built
upon OCB like RS-OCB can perfectlty do it though).
Akretion would happily do the work like 2 months per year I think. Now we
would need 5 more people/companies doing each 2 months eventually to cover
the rest of the year. I mean this is just a proposal, but let's see if the
idea is moving forward.

Again, OCB branches are no predating forks, they are just branches where
experienced people agree (through peer review) on collectively maintaining
a serie of patches that for some reason didn't make their way into the
official branches despite having merge proposals targeting the official
repos. That is, we understand OpenERP SA may not have resource to properly
review all community propositions and meanwhile we are avoiding to maintain
these patches individually with no critical mass to enforce overall quality.


Regards.

-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com





On Mon, Feb 24, 2014 at 7:58 PM, Pedro Manuel Baeza Romero <
pedro.baeza@xxxxxxxxx> wrote:

> Hi all,
>
> I'm wondering what will be the strategy for integrating all current
> patches on future v8 OCB that have been integrated on OCB v7 branch and
> that are not going to land on official v8 branch. Can it be easily
> automated?
>
> Regards.
>
> _______________________________________________
> 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
>
>