Hello Nhomar,
First, thanks to join in :) My answer/remarks inline : Le 7 nov. 2012 à 14:45, Nhomar Hernández <[email protected]> a écrit : > ... > 1.- We should add bugs, blueprint, and answer management to this project, if > we don't do that is the same that add a branch as Anthony proposed, dont you > think? => Of course ! We can, depending on the project, activate the part that make sense, but bugs seems to me a must have on every project > 2.- How we will intend to merge with OpenERP dev process?, i meas it should > be cool if we have 3 series [6.0 - 6.1 - 7.0] for every project? IMHO is the > best option, we are doing right now on addons-vauxoo project and > openerp-venezuela-localization and openerp-mexico-localization. => I though about making one serie per OpenERP Version (6.0, 6.1, 7.0), and no trunk as we always develop those modules on stable release. If we do need a trunk, will name it as the next version (like here, we already have 7.0) > 3.- We manage a simple politic, as we have several customers on 6.1 this is > our focus development (beause is where we are mantaining actually modules) > but we are in charge of mantain all 7.0 branches uptodate until we decide > start 7.0 devel. => Agree, focus of devs will always be the actual official last version, currently v6.1 > 4.- SOme Quality ensurance IMHO should be put Yaml Test in all your modules, > in this way migrate is REALLY less time'expensive, because all cases we test > in production (with test Yaml) explode inmediatly on 7.0 and you have a list > of explosions wuick to identify, FYI Migrate our Ven Localization has takes > less than the half of time Between 5 -6 and 6 - 6.1 and in one week we will > have 6.1 -7 what the best part is that 3 migration has been done for > different programmers, it shows the importance of readable tests . => Well, I'm always for tests adding, but some will not have time... I mean, I don't want to exclude some modules for that, but it should be strongly recommended ! > 5.- Im agreed with ptoject names, but, dont you think it should be less > difficult with: > > -- openerp-warehouse > -- openerp-purchase > -- openerp-logistic > -- openerp-sale > -- openerp-crm > -- openerp-conexions > > I mean just have different projects for different Functional Areas.... it is > just an idea. => Well I agree to change the names, but it starts to be long name like "openerp-stock-logistic-barcode".. The goal is to have them recorder under the project group "openobject" so in this page, you saw them all : https://launchpad.net/openobject (look at stock-logistic-barcode for example). Another point for more simple name for me is that we want the more "precise" project name to avoid the extra-addons mess... adding "openerp-" will make them a bit long, but if everyone agree with you, I can live with that ! Though ? Joël > -- Joël Grand-Guillaume Division Manager Business Solutions Camptocamp SA PSE A, CH-1015 Lausanne http://openerp.camptocamp.com/ Phone: +41 21 619 10 28 Office: +41 21 619 10 10 Fax: +41 21 619 10 00 Email: [email protected]
_______________________________________________ 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
