I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required).
Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum <adrian.c...@sandglass-software.com> wrote: > I agree with a separate community approach, for these reasons: > > The special purpose components started out as little demonstrations of how > OFBiz can be extended to role-specific applications. Since then, some of > those components have expanded into full-featured applications - so the > overhead of maintaining them has increased beyond what we expected initially. > > Some special purpose components were included as the result of a community > discussion and effort, but others were simply "dumped" into the repository > without any discussion or community participation - and as a result they > receive little support. > > Some special purpose components were created and initially supported by > community members who are not around any more. > > As a result of all of these things, the special purpose components are not > well maintained. > > From my perspective, if anyone believes a component needs more attention and > would like to develop it further, then they should spin it off to a separate > project. > > So, instead of having a conversation about how the OFBiz community can better > support the Project Manager component, maybe we should have a conversation > about how to spin it off to a separate community. > > Opentaps started off that way. Initially, it was OFBiz plus additional > components: Financials, CRM, and Warehousing. > > I think the OFBiz community would benefit if we stopped trying to be all > things to all people, and instead focus on providing a sound and flexible > data model - combined with robust, reliable services. Special purpose > applications, and even presentation layer details can be left to other > communities. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 11/7/2014 4:02 PM, Ron Wheeler wrote: >> I may be beating a dead horse but what Jacopo is proposing and the >> concern that Jacques raised about resources would seem to fit very well >> into a sub-project structure. >> Split these modules out of the main line into their own OFBiz >> sub-projects where they could attract their own resources (committers >> even) and would be responsible for delivering modules that worked with >> the various OFBiz cores that exist. >> >> Let the sub-projects worry about their own relationship to OFBiz >> releases and release branches. >> They might just support the released 13.07.xx version, if that is what >> the sub-project's user community can support or they might maintain 2 >> versions 13.07 and a 14.xx. that works with a recent version of the trunk. >> In any case, it would no longer be a problem for the OFBiz core >> developers and they could release just the OFBiz components that are >> officially part of the core. >> Clearly good communication between the core project and the sub-project >> about release plans would help everyone but the core group would be >> basically free to release the core as they want and the sub-projects >> would have to communicate to their uses communities what impact this >> would have on the users of the modules. >> >> If a sub-project needs a change to the core to implement some feature, >> they would have to file an enhancement JIRA issue and convince someone >> to add it (unless they are a committer on the core). >> If two sub-projects had a compatibility issue, they would at least know >> who to talk to get a solution. >> >> >> >> Ron >> >> On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: >>> On Nov 7, 2014, at 12:36 PM, Jacques Le Roux >>> <jacques.le.r...@les7arts.com> wrote: >>> >>>> This will no longer work for some components (scrum for instance) >>>> >>>> I believe we could be reintroduce some specialpurpose component in >>>> next release, >>> There is a difference between including them in a release branch and >>> including them in the releases: I would be more inclined to include >>> (all of them) in the release branches but exclude them from the >>> releases; this would simplify the work required to keep them in synch >>> and would also help end users to integrate them. >>> However the specialpurpose components should be disabled in order to >>> avoid the users to get a default ootb release/branch with enabled >>> special purpose functionalities that may override the more general >>> purpose ones offered by the core applications. >>> We should still consider the idea of providing separate products for >>> the specialpurpose components (and having them in the branch would >>> help this process). >>> If the idea I am proposing here (include the specialpurpose components >>> in the branch but not in the releases) we could re-add them (as >>> disabled) also to the 13.07 branch but exclude them from all the >>> releases (13.07.02 etc...): this will protect all the stabilization >>> work we did on the branch (and also from some licensing issues that >>> may affects some of the artifacts in some of the specialpurpose >>> components) . >>> >>> Jacopo >>> >>>> as long as they are backed by some efforts, come to mind >>>> project manager (Pierre Smits?) >>>> scrum (Hans?) >>>> examples and ext (at least me) >>>> myportal (French people use portals, not sure for myportal?) >>>> >>>> Other components? >>>> >>>> IRRW Jacopo said he was not against a new discussion on this subject >>>> (I could not find his message), what do you think? >>>> >>>> Jacques >>>> >>>> Le 21/10/2014 09:06, gil portenseigne a écrit : >>>>> I've never used svn external property, just discovering. That sounds >>>>> usefull and i'll try it out ! >>>>> >>>>> Thanks for the advice ! >>>>> >>>>> Gil >>>>> >>>>> >>>>> On 20/10/2014 19:08, Jacques Le Roux wrote: >>>>>> I use svn external in the stable demo, already explained that in >>>>>> the MLs: see >>>>>> https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup >>>>>> >>>>>> You can use the same to keep in sync, only consider projectmgr in >>>>>> your case. Since there is no projectmgr in R13.07 the risk of >>>>>> gettins conflicts or build issue is extremely low >>>>>> >>>>>> Jacques >>>>>> >>>>>> Le 20/10/2014 17:28, gil portenseigne a écrit : >>>>>>> Hi Jacopo, >>>>>>> >>>>>>> Ok then, i will have to re-synchronize new trunk devs each time >>>>>>> i'll feel it necessary. My fear is about incompatibility between >>>>>>> 13.07 and trunk technologies, but that won't happen soon, or i >>>>>>> might backport the evolution into my local environment. >>>>>>> >>>>>>> That will do the job ! >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Gil >>>>>>> >>>>>>> On 20/10/2014 16:36, Jacopo Cappellato wrote: >>>>>>>> Hi Gil, >>>>>>>> >>>>>>>> I would suggest to check it out from the trunk to the hot-deploy >>>>>>>> folder of 13.07: >>>>>>>> >>>>>>>> cd hot-deploy >>>>>>>> svn co >>>>>>>> http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr >>>>>>>> >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>> >>>>>>>> On Oct 20, 2014, at 4:11 PM, gil portenseigne >>>>>>>> <gil.portensei...@nereide.fr> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I don't want to relaunch the debate around including the >>>>>>>>> projectMgmt component into the 13.07 release, but i have a >>>>>>>>> question : >>>>>>>>> >>>>>>>>> What is the best way to import the projectMgr component in my >>>>>>>>> local 13.07 checkout environment, to start using it in a real >>>>>>>>> project and to contribute on upgrading it for trunk and/or the >>>>>>>>> 13.07 release ? >>>>>>>>> >>>>>>>>> Trunk technical evolution might be a problem if a want to stick >>>>>>>>> to 13.07 release with projectMgmt features. >>>>>>>>> >>>>>>>>> Should I use trunk instead ? >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> >>>>>>>>> Gil >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> <siteon0.jpg> >>>>>>>>> >>>>>>>>> Gil Portenseigne >>>>>>>>> Consultant ERP OFBiz >>>>>>>>> Société Néréide >>>>>>>>> 3b Les isles >>>>>>>>> 37270 Veretz >>>>>>>>> Tel : 09 74 53 46 09, puis 1, poste 61 >>>>>>>>> Mob : 06 82 740 444 >>>>>>>>> www.nereide.fr >>>>>>> >>>>> >>>>> -- >>>>> <Mail Attachment.jpeg> >>>>> >>>>> Gil Portenseigne >>>>> Consultant ERP OFBiz >>>>> Société Néréide >>>>> 3b Les isles >>>>> 37270 Veretz >>>>> Tel : 09 74 53 46 09, puis 1, poste 61 >>>>> Mob : 06 82 740 444 >>>>> www.nereide.fr >>> >> >>
