openerp-community team mailing list archive

[Leonardo Pistone <leonardo.pistone@xxxxxxxxxxxxxx>]

Raphaël, Pedro, Nhomar,

I just checked the travis-ci setup for openerp-brazil and it's the kind of
thing that resonates with me: it has a very simple configuration, it's
already there (and free as in free beer). It looks like it can very easily
extended to multiple environments (py2.6, py2.7, official + ocb). Also, it
can easily extended to display coverage (coveralls.io for example), include
some flake8 checking in the test script, and use alternate testing methods,
like openerpscenario.

Compared to runbot, it has no ability to test instances manually.

So, I'm all for a small trial and careful move. Of course this has to be
decided by the OCA.

Thanks,
leo


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

> Hi, Raphäel,
>
> If the translations are not a problem, I see then reasonable to try with
> one pilot Launchpad project to split on GitHub subprojects and see if all
> goes right. What the others think? Can we try?
>
> Regards.
>
>
> 2014/1/7 Raphael Valyi <rvalyi@xxxxxxxxx>
>
>> On Tue, Jan 7, 2014 at 4:50 PM, Nhomar Hernández <nhomar@xxxxxxxxx>wrote:
>>
>>>
>>> 2014/1/7 Raphael Valyi <rvalyi@xxxxxxxxx>
>>>
>>>> sorry, I don't understand what is wrong with the transition path I
>>>> described, to sum up:
>>>
>>>
>> @Nhomar, answers in line:
>>
>>>
>>> My Friend,
>>>
>>> The main issue is: we need solve with Pedro's question a problem of 1
>>> line on the __openerp__.py which is what is being taking into account on
>>> apps.
>>>
>>
>> Which I answered basically by "let it go for now for the z of x.y.z"
>> until we have some automated tool, which as the advantage of keeping things
>> simple, no?
>>
>>>
>>> And you expend a lot of time explaining again the git stuff "Mixing
>>> different things.".
>>>
>>> The main issue IMHO is that we can not establish a path based in an
>>> integration between 2 tools which are not managed by community instead of 1
>>> team (Akretion't team).
>>>
>>
>> It's not because I've been pioneering this that this cannot be an OCA
>> managed thing? Why couldn't such a 10 lines cron be managed by OCA just
>> like the bzr replay thing? OK at some point a server is needed to run the
>> script, but really I don't see why it's so impossible to overcome, how is
>> that different from the bzr replay of OCB? As I stated since the start, I'm
>> all for granting these branches to some OCA account once it becomes of
>> interest to OCA.
>> The initial setup isn't that simple I need some time to blog about it
>> (but hey I should pass a certification for now ;-), but then the
>> maintenance of it is pretty straightforward. But please don't try to make
>> it look I propose that to have control over it. It's not I propose that for
>> us to be more productive daily, that's it.
>>
>>
>>> Let's only write the rule for the line 'version': x.y.z on the
>>> __openerp__.py and we can offer a different solution for the rest of stuff
>>> you mentioned before (which are important, relevant and can be taken into
>>> account but they are out of this thread).
>>>
>>
>> Well IMHO they are just extremely related. As you can see Vo Minh Thu we
>> spent may be 2 or 3 years inside OpenERP SA took no other path than
>> versionning  modules after their VCS numbers. And as we have seen, bzr
>> revno doesn't make the cut and Assertive solution still has an issues
>> because the version doesn't reflect changes in modules (there are lot's of
>> false positive).
>>
>> Semantically, the z of x.y.z could reflect something different than just
>> a change in the module. But I say that if z means module changed, then this
>> is kind of stupid and error prone to require to maintain it manually
>> instead of automatically.
>>
>>
>> @Pedro,
>>
>> about Rosetta: we can absolutely keep using Launchpad and Rosetta for
>> translations. First OpenERP SA branches will still be made on LP (until
>> said otherwise), where they can be translated as before. Now if some Github
>> based project wants Rosetta translation, it's just about mirroring it to LP
>> (automatic, no server script required for the main branch, 3 lines
>> otherwise), get it translated on LP and then merge it automatically back in
>> Github. This is really straightforward and as I said, I can help with the
>> tooling f there is any doubt about that.
>>
>> Again git bzr remote helpers are part of git core now and are two ways
>> sync. The only very issue is it doesn't support bzr stacked branches which
>> makes it slow for the addons. But it can still be used for daily things
>> like translations.
>>
>> Again, nobody reads me wrong please: I'm not urging to move anything to
>> Github. I'm just saying, I think the best solution to the z number of x.y.z
>> is that VCS number on an module specific branch which we cannot achieve
>> with bzr: Antony Lesuisse, Joel Grandguillaume and me, each spent over 2
>> days on this individually at the extra addons decommissioning came with no
>> better solution than my ruby extractor script that rely on bzr replay but
>> is way too slow and unperfect to be used automatically at such a scale. I'm
>> proposing this path as a smooth evolution.
>>
>>
>> Finally, until that z numbers comes from the VCS, we could eventually
>> having a bot with scanning changes in branches and incrementing the number,
>> but I feel it's just a waste of time instead of moving toward the true
>> solutions.
>>
>>
>>
>> Regards.
>>
>>
>> --
>> Raphaël Valyi
>> Founder and consultant
>> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
>> +55 21 2516 2954
>> www.akretion.com
>>
>>
>>
>
> _______________________________________________
> 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
>
>