ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taher Alkhateeb <slidingfilame...@gmail.com>
Subject Re: How to use ProjectMgr in 13.07
Date Fri, 07 Nov 2014 19:08:38 GMT
Hi Everyone, 

I do not have a long history with the OFBiz project to understand its history, but from the
last few years I noticed the following: 

- The system is huge 
- Documentation is wanting 
- The community is suffering from low number of experienced developers 

For example, I use and want to support the BIRT reporting component. Yet there are very few
committed developers experienced and comfortable enough in maintaining it and upgrading with
new releases. So, I would imagine taking it out as an almost sure death sentence given the
already low resources. 

With all due respect, talking about sub-projects and plans and resources and commit access
and all of that stuff does not make sense when you barely have enough experienced people maintaining
the code. I see only a few names over and over who are doing the "real" heavy work. 

So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other
suggestions would probably kill any less heavily maintained components. 

Taher Alkhateeb 

----- Original Message -----

From: "Ron Wheeler" <rwheeler@artifact-software.com> 
To: dev@ofbiz.apache.org 
Sent: Friday, 7 November, 2014 9:29:05 PM 
Subject: Re: How to use ProjectMgr in 13.07 

I was trying to find some Apache docs about what is involved. 
Separating the SCM controls so that the sub-projects can have their own 
committers is an important task. 
Any idea about what else is required? 

In any case, it would be the people who want to support the sub-project 
to do the paperwork. 

There is clearly nothing to stop a fork of any part of OFBiz but there 
is some advantage to keeping OZBiz in one piece. 
The most important thing is that it allows the sub-project to use the 
OFBiz name and Apache branding in its "marketing" material and 
It also builds the pool of potential contributors and committers for the 


On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: 
> 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.crum@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.roux@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
>>>>>>> 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
>>>>>>> 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
>>>>>>>> i'll feel it necessary. My fear is about incompatibility
>>>>>>>> 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
>>>>>>>>> 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.portenseigne@nereide.fr> wrote: 
>>>>>>>>>> Hi all, 
>>>>>>>>>> I don't want to relaunch the debate around including
>>>>>>>>>> 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 

Ron Wheeler 
Artifact Software Inc 
email: rwheeler@artifact-software.com 
skype: ronaldmwheeler 
phone: 866-970-2435, ext 102 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message