On Wed, Oct 31, 2012 at 10:43 AM, Joël Grand-Guillaume < [email protected]> wrote:
> Hello again, > > > In the same topic, it'll be great to have a common naming convention for > all those branches what do you think ? I would suggest to have one branch > per OpenERP version that will be easily recognizable, with the following > naming: > > Name-Of-Project/OpenERP Version > > Like : > > lp:c2c-financial-addons/7.0 > lp:c2c-financial-addons/6.1 > > Are you ok with this ? > Hello Joêl, Well basically yes. More precisely: - branches that really have a significant topic can go inside a project and get a bug tracker, a mailing list and all what LP offers. - because of historical reasons (like extra-addons, in-house modules of Company X...), there will likely be several branches in the same topic: like extra-financial-addons and c2c-financial-addons. Eventually these branches get merged in the future, but let's move one step at a time instead of claiming upfront perfection and doing nothing - inside these projects, there will be Launchpad series reflecting OpenERP versions - these branches will be registered at apps.openerp;com to make OpenERP SA happy - while this is extremely hard to tolerate some unskilled middle men unable to win money by their own work now trade money to fraud open source reputation over our back, I still hope our community work don't collapse under the mean paranoia to name modules or projects after the initial company who started it. Remember Magentoerpconnect started at Smile and called smile_magento_connector. The history changed, they stopped maintaining it and it took a rewrite from scratch to build a company agnostic module name. Hopefully collaboration wins over fragmentation, but this depends on all of us. Now, yes at Akretion we have been friendly enough for not putting our company name in every single module we develop but still got nearly rapped by those motherfucker middlemen. So in any case I understand the issue, but my message is fight the middlemen and try to keep collaborating, make code authors explicit, educate the community. - at Akretion we are likely to mirror these branches on Github and use Travis-CI to get them automatically tested at every commit. Again, as I explained in a previous thread, OpenERP SA didn't convince us at all they take module dependencies and lifecycle seriously enough (what they proposed doesn't match what we do and we are among the few making a living from integration OpenERP...) so this and the need to be able to apply and test suite (and test suite technology) top any branch (so with any dependencies) justifies IMHO looking at Travis-CI for automatic testing of community branches (instead of waiting OpenERP 12 to get some notion of version dependencies). - at first we will use Github mirroring only for testing and possibly for deployment (despite all the doc, merging a stacked branch after 2 months is still painfully slow, but we need to do that for every single customer). But eventually we may reverse the situation for a few very active branches and develop on Github while mirroring on Launchpad to make grandma style developers happy. I'll be doing the proposed module extraction today and will report how it worked. 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-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
