openerp-community team mailing list archive

[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