About v8, I support the initial idea of splitting the modules into many small repos. Let me argue a bit about this:
- especially with git, it is super-easy to make branches even for small modifications. Having many modules in the same branches means that if you have two feature branches that add or change two different modules in the purchase-wkfl project, you cannot use them at the same time, not cleanly. - once (soon, I'm sure!) we will have travis test runs for unit tests and flake8 on all oca branches, we will be able to see in github that a branch is green and that a PR makes it red. Small repos make it super-easy to find the culprit and take action. The test runs become smaller, faster and more atomic. This will make our life as code reviewers incredibly easier IMHO, in addition to the "merge" button. Git submodules or subtrees are tools that group together many repos in a big repo as subdirectories. This basically means that we get the best of both worlds (we have the original big repos that have the modules as subtrees/submodules). I do not believe these to be black wizardry: it is just that git is used in big projects with many modules, and being very much used, good and generic solutions for those problems we have problems are already there. The disadvantages seem very small to me: - Finding the projects is harder: I do not believe so. There will be the subtree repo looking like the old ones, plus we can look them up in a wiki page / apps site or something. - Needs some initial work by some git experts: True. Someone with more experience than me could give more details please? I believe Joël for example make some research in that. For v7, I still think that the original a) proposal by Joël or making an as-is mirror of the v7 branches immediately on github, with a read-only mirror back to launchpad is my favorite option. Reason: when we will start to work on v8 on github, it will be complex to handle the two at the same time. Thanks to all for your time! best On Tue, May 20, 2014 at 12:18 PM, Joël Grand-Guillaume < joel.grandguilla...@camptocamp.com> wrote: > Dear all, > > > Thanks a lot for all your feedback here. So, to summarize opinions here: > > * Version <= 7.0 keep Launchpad as a reference. We eventually setup a > replication in github (lp -> gituhub) in a couple of weeks > > * We do use one organization on github for the whole community work > > * We create one team on github per area of expertize (so that means like > it is now on LP). I tried to see if we can lower the number of team, but > wasn't able to decide how to merge them. Any though here, the list is here : > https://launchpad.net/~openerp-community-reviewer/+participation ? > > * Every LP project become a repository on github. The branches hosted > under the community reviewer team (bazaar extractor, etc..) will have a new > repo called something like "community toolkit". > > * Branches represent the serie (like OpenERP did with odoo) > > The only disadvantage I see here is that we cannot include a team in a > team on github. So that means, we'll no longer have a community reviewer > team that is part of all other team. We'll need to add in every team the > right people, but apart from a bit of "administrative" work, it'll be ok. > > As Nhomar pointed out, I already took the time to create this organization > on github : https://github.com/OdooCommunity > > It was a first test from me, but if you agree, I'll spend some time to > create the team and repos. I suggest also that I make an OCA-board team > with the administration right on the organization. So current OCA board > member will be able to administrate the organization as well. > > As some of you already notice, I also took the liberty to make a new logo, > keeping the ant ;) Hope it please you all ! > > Regards, > > Joël > > > > > > On Tue, May 20, 2014 at 9:16 AM, Alejandro Catalina > <alecat...@gmail.com>wrote: > >> Hi there, >> >> I also agree with the last proposal, one github organization and several >> repositories, one for each launchpad project. >> >> So let's move on. I think the best way to move all those projects and >> branches is to divide the work between all of us. We could make a list of >> all launchpad URL involved and begin the job. >> >> What do you think about? >> >> >> 2014-05-20 8:33 GMT+02:00 Quentin THEURET <q...@tempo-consulting.fr>: >> >> On 16/05/14 18:43, Maxime Chambreuil wrote: >>> > We agree with Stefan here. >>> >>> I'm also agree with Stefan point of view. >>> >>> Regards, >>> -- >>> Quentin THEURET >>> >>> TeMPO Consulting >>> 20, Avenue de la paix >>> 67000 Strasbourg >>> France >>> >>> http://www.tempo-consulting.fr >>> Tel : +33 3 88 56 82 18 >>> Fax : +33 3 88 56 46 64 >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openerp-community >>> Post to : openerp-community@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openerp-community >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : openerp-community@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp >> >> > > > -- > > > *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: https://launchpad.net/~openerp-community > Post to : openerp-community@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
