The barrier to working on the framework is a technical one. Anyone
wanting to work on the framework must understand these things:
1. OFBiz design philosophy and its high-level design.
2. Design patterns (ie GOF).
3. Concurrency (database and Java).
4. Commit history.
It would be wonderful if more people would get involved in the
framework. It just takes a bit of research, and a little time asking
questions from those who have been working on it for a while.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 11/7/2014 8:21 PM, Ron Wheeler wrote:
Taher Alkhateeb raised some valid concerns.
My take (also as a newcomer) is that there is a high barrier to entry
for people working on the framework and this makes it hard to get new
people into the OFBiz project.
By creating sub-projects that have a much smaller scope and do not have
any affect on the overall robustness of the system, we would allow new
people to take on tasks that have a much narrower scope and are more
in-line withtheir abilities and interests.
It will also allow OFBiz to attract subject matter experts on certain
areas such as the BIRT language, data analysis, project management or
manufacturing who are not attracted to the framework development tasks.
The current level of complexity forces the group to be a small band of
dedicated people who have the detailed technical understanding of the
framework and tools used to build and maintain it.
There is nothing to prevent framework contributors from also joining
sub-projects where they have an interest.
It would also provide a level of transparency about what is getting
supported.
If no one is active in the BIRT sub-project, at least you know that it
is not supported.
At the moment, you have no idea about the interest in supporting BIRT.
If you need it and it is not supported, currently you do not have anyone
to talk to except the framework mailing list.
If it had its own sub-project, you would have a leader and a list of
people who once had an interest in it.
If no one was interested in your BIRT issue, you could always hire
someone to work on the bits that you needed fixed.
If BIRT is completely orphaned,you could take over leadership of the
BIRT sub-project and get it back going.
I think that the project management and SCRUM projects could probably
put together sub-projects.
You would have to do a bit of work to get a BIRT group growing.
However, it looks like a good candidate for a separate project since
BIRT is a completely different programming language and a lot of the
skills have to do with business analysis, usability and data analysis
rather than Java coding.
You might find that a BIRT sub-project attracts a number of people who
would not be interested in supporting the framework.
Sub-project will also reduce the amount of traffic on the dev list and
allow people to focus on what they think matters to them.
They also allow other people to take on leadership roles in these areas
which reduces the burden on the current core contributors.
Sub-projects are a key part of many Apache projects, so I believe that
they must serve a useful purpose.
I think that this project is really in need of a way to grow the
community without diluting the quality and I see sub-projects as a way
to keep the focus within Apache OFBiz rather than fork the parts into
outside open source projects which is the current direction.
Ron
On 07/11/2014 2:08 PM, Taher Alkhateeb wrote:
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" <rwhee...@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
documentation.
It also builds the pool of potential contributors and committers for the
core.
Ron
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.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
