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 <[email protected]> > On Tue, Jan 7, 2014 at 4:50 PM, Nhomar Hernández <[email protected]> wrote: > >> >> 2014/1/7 Raphael Valyi <[email protected]> >> >>> 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 : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
