← Back to team overview

openerp-community team mailing list archive

Re: Version numbering

 

On Tue, Jan 7, 2014 at 3:22 PM, Pedro Manuel Baeza Romero <
pedro.baeza@xxxxxxxxx> wrote:

> Hi, Raphäel,
>
> I would love also to have a decent package manager, but we still have the
> same problem with git that we had months ago: a way to make translations as
> easy as with Launchpad. Do you know any way to perform this?
>

Hello Pedro,

sorry, I don't understand what is wrong with the transition path I
described, to sum up:

   - we stick to LP as the primary forge for now
   - I offer to set up git mirrors of OCA projects like I did for the
   official branches https://github.com/akretion
   - we start (I can do it) doing automatic git subtree extraction of all
   these modules so we can use them as the entry pipe of some tool like
   Assertive that generates instalable Python modules with their proper
   versions (I can do the extraction but I need some commitment from others
   for the modules packaging/hosting)
   - In the meantime we take some pilot project where main author like git
   and switch their forge to use Github as the primary forge and LP as the
   mirror
   - In the meantime I help with the "nag" tools so that OCA get integrated
   reporting about the pending merges, whether they are on LP or Github.
   - Progressively we abandon LP totally as the primary forge (unless for
   translations updates may be).
   - At the ed of the process, people work on branch of individual modules
   on a git forge. (could probably be done with Mercurial too but I can help
   only if we pick git).


Remark: we switched Launchpad for Github as the primary forge of the
Brazilian localization some 5 months ago. Since now we are using the git
flow process http://nvie.com/posts/a-successful-git-branching-model/ and
zero cost automatic tests on Travis
https://travis-ci.org/openerpbrasil/l10n_br_core
We reveive now more contributions now (see on the right with SHIFT+L)
https://github.com/openerpbrasil/l10n_br_core/network
(in fact new comers know Github already while they are reluctant to learn
LP; the lower branch activity went to a separate project via git subtree to
be complete)

And in a word, let's say we liked the move a lot.

Some additional consideration:

In fact, the place where working on git would be the most appreciated would
be OCB. Why? Because addons is the true hassle to download with bzr (slow)
and today OCB branches are a hassle to merge with official branches. v8
won't be out before Q2, but in fact I'm sure many would like to have trunk
branches (saas1, saas2..) merges into OCB branches. Currently this is a
hassle to do on LP (but doable still) while this is a lot easier on git. I
did it in no time for server and web (addons would cots a few hours to fix
10 python conflicts or so). I would like to know what it would take to get
OCB done on Github (bug cross referencing, that kind of things). Let's say
I would like it, but if people want to do these branch with bzr replay
script, I will help on LP too.

Again, don't read me wrong, I don't say OCA is wrong to use LP, as long as
OCA will want to stay on LP, I will help on LP. I'm just trying to draw an
escape plan where we can achieve a better productivity with OpenERP so we
can scale this product instead of spending time on manually dealing with
dependencies.

Regards.

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






>
> Regards.
>
>
> 2014/1/7 Leonardo Pistone <leonardo.pistone@xxxxxxxxxxxxxx>
>
>> Hi Nhomar, Raphaël, Pedro,
>>
>> I suppose that bzr revno could be a problem because it is not absolute
>> (numbers can be duplicated across branches, and get reassigned when you
>> merge).
>>
>> Best, Leo
>>
>> _______________________________________________
>> 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
>>
>>
>

Follow ups

References