openerp-community team mailing list archive

[Pedro Manuel Baeza Romero <pedro.baeza@xxxxxxxxx>]

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