On Fri, Oct 25, 2013 at 12:45 PM, Nhomar Hernández <[email protected]> wrote:
> > 2013/10/25 Pedro Manuel Baeza Romero <[email protected]> > >> I know too about runbot availability to run locally downloading source >> code, but the added value of runbot is to have it on-line, as Travis CI >> does. Anyway, I also see more interesting Launchpad / GitHub debate. >> @Fabien, have you talked about the switch internally? > > > I think It is a different discussion. > > 1.- Travis doesn't have "Auto Build ready to test" feature, and is written > in Ruby and double licence problem. > > 2.- Launchpad is totally open and runbot. > > 3.- Runing runbot "Teach You" more deeply openerp, Running Travis "teach > you ...." well Travis. > > 4.- The translation management is not possible/comparable in github like > in Launchpad. > > 5.- The transition is not only "Move the branches" we need to move > internal process, internal developments that automate bzr projects and so > on. > > IMHO: This change should be approved / done at least 6 moths __before__ > move something, but even, compare bzr and git is a matter of religion > because both have the "same" posibilities i we read "Both" manuals. > > BTW, it is only my opinion, the Positive impact is so little compared > with the cost it can bring. > > My 2 Cents. > Hello, despite we use Github a lot and that I personally even prefer Ruby, I also think that there are much more urgent things than change the forge of the core. What we have works as a forge fo the core. Unlike Github, it's not easy, it require times to understand Launchpad awkward organization, but anyway, people contributing to the core should be experienced, so it's not so terrible practically. Also, answering about Travis double licence: I should say that I'm more worried about the absence of credible business model at all behind Launchpad and bzr than by what I find a credible business model for Github and Travis while still making everything that matters in the open. I'm even afraid of these tools get anywhere in the long run. In fact, what sucks the most with bzr is that it's slow to checkout and pull. So here we use git as a deployment tool, but for the forge we keep using Launchpad where the core teams work. We use Github for other OpenERP projects that were not initially located on Launchpad, and also for the Brazilian localization because lot's of people who had some fiscal knowledge and would contribute didn't know Launchpad and asked us to make the switch. And it works: https://github.com/openerpbrasil/l10n_br_core/pull/14 And as I told we use Travis for testing because of the liberty and zero cost it offers us. But I don't propose changing the forge itself at least until 2015. Again what is cool is that people have the choice and we don't need to bother OpenERP SA with the tools we prefer or not. As for Olivier's proposal about OCB, well I agree fully with Stefan's answer. bzr and Launchpad are less oriented toward cherrypicking and decentralization than git/Github. So unfortunately we should limit the number of branch layers we maintain to assure their critical mass. As such, I also assume the same pragmatic stance as Stefan's: today the real OpenERP integrators tend to be alien skilled people that don't fear a schema change or two if it really saves their life in their projects. So I also assume that OCB can be less dogmatic about very occasional schema changes. The millions of SaaS users that cannot afford doing -u on their instance doesn't match my reality. Mine is that bugs should be fixed no matter if it requires very occasional schema changes that makes consensus among the best integrators. Eventually there are different branches for different needs. best regards.
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
