Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: Migration to version 9
by
Elico Corp, Eric Caudal
+1 for one module one repo
Actually the idea of grouping is intrinsic to the module naming sale_*, website_* etc.
Additional Pros: searching for module is easier in github
Actually the idea of grouping is intrinsic to the module naming sale_*, website_* etc.
Additional Pros: searching for module is easier in github
--
Eric Caudal [Founder and CEO]
Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 (Office)
Elico Shanghai (Shenzhen/Singapore) Odoo Gold Partner, best Odoo Partner 2014 for APAC
Eric Caudal [Founder and CEO]
Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 (Office)
Elico Shanghai (Shenzhen/Singapore) Odoo Gold Partner, best Odoo Partner 2014 for APAC
On 08/27/2015 04:23 PM, Yannick Vaucher
wrote:
<blockquote
cite="mid:CAA50gnEjHAkEZc22K6BWC_c0Rm8n8MPMTFv=0ZMiGKo6n2LHRQ@mail.gmail.com"
type="cite">
Thanks for the proposal. Just a thought, what the difference between merging an addon with filter branch in same repo and merging the module with filter branch in a separate repository to have one module per repository? (filter branch might be done correctly by looking at the history to filter all old names of the module. You can filter multiple directories. It could be automated assuming we know all module renaming which is the tricky part) I still strongly believe that it would be a good choice to take the path of one *module per repo*. Here are the pros and cons: ***Cons*** *Changing things* All change of structure have a time cost. Is it worth it? *Management on github* More repo = more access rights to manage. *Group by themes* Splitting modules which were grouped by themes Can we keep our group of modules by topics as we are doing it now? Would it be better or worst to group those modules elsewhere than on github? *Tests* Tests are separated they wouldn't be tested together. ----------------- ***Pros*** *Version of modules* We can set module version on github tag. Right now you can download modules at the same repo version. If you want to freeze module 1 at version X and module 2 at version Y it starts to be tricky. Could it be the road to make eggs? *Apps.odoo.com* modules are registered by repo. If a single module name conflict in the repo all modules cannot be updated anymore. *Dependencies* We can rely on __openerp__.py to get dependencies and we could rely on the repository name to search for the right addon. No more "Where is my damn addon named XXX" *Group by themes* Refering our modules outside of github could make us have same module in multiple categories. Some times you want a module to be present in multiple topics. Solutions could be git sub-tree to keep the groups on github. *No more PR with 4 modules migrated at the same time* When it comes to migrate things you have to migrate dependencies. That mean you have to deal with big PR or multiple PR that depends on each other which somehow could conflict. *Tests* Tests are separated this avoid conflicts. Could we use git subtree to test multiple modules together? Those are just raw thoughts I'm surely missing something. Feel free to complete it or disaprove on some parts of it. Yannick Vaucher Business Solutions Software Developer Camptocamp SA PSE A, CH-1015 Lausanne Phone: +41 21 619 10 30 Office: +41 21 619 10 10 http://www.camptocamp.com/ On Thu, Aug 27, 2015 at 9:37 AM, Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote: > Hi, > > > Thanks for the initiative ! I'm also in favor of deleting the __unported__ > folder. But -1 for using git filter-branch and moving each module (a clean > git history matter). > > So as a summary of what I read: > > * +1 for not using the __unported__ folder > * Not fan to use git filter per module and prefer merges > * Two options to keep module at root folder and not use git filter : > > a) active = False in the manifest > b) Renaming the __openerp__.py to __unported.py__ > > I prefer b) because I don't need to edit the file to know if it is ported or > not. > > Regards, > > Joël > > > > > On Thu, Aug 27, 2015 at 8:38 AM, Guewen Baconnier > <guewen.baconnier@camptocamp.com> wrote: >> >> Thanks for this proposal! >> I strongly agree with the removal of __unported__. >> But I'm -1 for the migration per module using filter-branch for the >> same reason that Stéphane and for another very reason: it does not >> support the renaming of a module so the history would stop at the >> first git mv. >> >> -- >> Guewen Baconnier >> >> On Wed, Aug 26, 2015 at 8:23 PM, <Bidoul@pad.odoo-community.org> wrote: >> > Another big con is that the forward port process by a git merge of 8.0 >> > into >> > 9.0 is not possible. >> > >> > I'll think to it a little bit more but I'd say at this stage I'm not a >> > huge >> > fan of this method. I believe the disadvantages outweight the small >> > benefit >> > of hiding unported modules. >> > >> > At some point there was a proposal of >> > - keeping unported modules with active=False >> > - having an (autogenerated) list of modules and their status in the >> > README.md of the repository >> > >> > That proposal plus an systematic forward port process is my favorite >> > approach at this point. >> > >> > -sbi >> > >> > On Wed, Aug 26, 2015 at 7:52 PM, <Pedro@pad.odoo-community.org> wrote: >> >> >> >> Pros of this method: >> >> >> >> Avoid a lot of commits starting the branch. >> >> Avoid commits of deprecated modules. >> >> Avoid having outdated version that was put on __unported__ when release >> >> version was out, but later modified on the previous version. >> >> Avoid forgetting to use the version in __unported__. >> >> No misunderstanding for newcomers about the existence of the module in >> >> the >> >> __unported__ folder. >> >> No need to remove any module. >> >> >> >> Cons of this method: >> >> >> >> It requires a process to start a PR a bit more complicated than before. >> >> Reviewers should check if the commit history is well-extracted. >> >> Contribution statistics are disturbed by this process (although it can >> >> be >> >> easily filtered by distinct commits). >> >> >> >> So we think the number of pros is better than the cons, and that's why >> >> we >> >> propose this. >> >> >> >> Please comment any possible thing we haven't figure out. >> >> >> >> Regards. >> >> >> >> >> >> >> >> 2015-08-26 19:23 GMT+02:00 Maxime Chambreuil >> >> <maxime.chambreuil@savoirfairelinux.com >> >: >> >>> >> >>> Dear OCA contributors >> >>> >> >>> Pedro and I proposed a new process to manage the coming migration from >> >>> 8 >> >>> to 9 : >> >>> >> >>> >> >>> https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9-%28WIP%29 >> >>> >> >>> Main thing is to get rid of the __unported__ directory as it contains >> >>> outdated versions of modules. We want to migrate the latest version >> >>> and >> >>> avoid duplicating PR against many branches. >> >>> >> >>> Version 9 is still more than a month ahead, so we have time to review, >> >>> discuss and agree on this proposal. >> >>> >> >>> Cheers, >> >>> -- >> >>> Maxime Chambreuil >> >>> +1 (514) 276-5468 #126 >> >>> >> >>> _______________________________________________ >> >>> Mailing-List: http://odoo-community.org/groups/oca-contributors-15 >> >>> Post to: mailto:contributors@odoo-community.org >> >>> Unsubscribe: http://odoo-community.org/groups?unsubscribe >> >> >> >> >> >> _______________________________________________ >> >> Mailing-List: http://odoo-community.org/groups/oca-contributors-15 >> >> Post to: mailto:contributors@odoo-community.org >> >> Unsubscribe: http://odoo-community.org/groups?unsubscribe >> > >> > >> > _______________________________________________ >> > Mailing-List: http://odoo-community.org/groups/oca-contributors-15 >> > Post to: mailto:contributors@odoo-community.org >> > Unsubscribe: http://odoo-community.org/groups?unsubscribe >> >> _______________________________________________ >> Mailing-List: http://odoo-community.org/groups/oca-contributors-15 >> Post to: mailto:contributors@odoo-community.org >> Unsubscribe: http://odoo-community.org/groups?unsubscribe > > > > > -- > > > camptocamp > INNOVATIVE SOLUTIONS > BY OPEN SOURCE EXPERTS > > Joël Grand-Guillaume > Division Manager > Business Solutions > > +41 21 619 10 28 > www.camptocamp.com > > > _______________________________________________ > Mailing-List: http://odoo-community.org/groups/oca-contributors-15 > Post to: mailto:contributors@odoo-community.org > Unsubscribe: http://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List:
http://odoo-community.org/groups/oca-contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe
Reference
-
Migration to version 9
byOpen Source Integrators, Maxime Chambreuil-
Re: Migration to version 9
byClosingAp Open Source Integrators Europe, LDA, Daniel Reis