On 09/11/2014 10:45 PM, Scott Gray wrote:
I still think you're putting the cart before the horse. I'm not
sure I could name any specialpurpose component that has the two or
three active contributors that I think would be necessary to sustain it.
It will become apparent when the team or person steps forward to
maintain it.
If they won't contribute to it now then why would they suddenly jump
at the chance to run it? It seems silly to me to go through the
effort of setting up a sub-project then waiting a few months to pull
it back down because no one cares.
You don't set up a sub-project until someone asks for it with a plan to
do something with it.
You seem to be running on the premise that some of these components
have active contributors. I'd love to know which components these
are. I'm not talking about a vaguely mentioned interest, I'm talking
about actual action taken. There are hundreds of open source projects
I'm interested in and roughly 1-2 I have time to contribute to.
Project management seems to be ready for some action.
eCommerce seems to have some following which could be enlarged if there
was a way to engage a larger community.
The activi integration seems to be developing a team.
I suspect that localization might attract some contributors if it could
be set up as a sub-project.
Particularly for security issues, the TLP PMC cannot simply ignore
dormant sub-projects, we have to take action if a report comes in.
Why?
The report would go to the sub-project.
If the project was still shown as "active " on the project web site and
if there was no response to the request, the person making the request
would contact the sub-project leader.
If th project was dead and was "officially" not being maintained, the
person would have 2 next step; fix the issue on their own using the last
source available or ask on the sub-project mailing list for help from
other users of the module to see if the project could be resurrected.
Most of questions I asked were based on the premise that the given
sub-project was dormant (sorry if I didn't make that clear), but you
answered with the "sub-project will take care of it" so I guess it
wasn't clear. If a sub-project is dormant (which I think is highly
likely to be the outcome), then it falls back to the PMC to deal with
monitoring, receiving contributions, determining suitability of
prospective committers and dealing with security issues. Not to
mention the set up and tear down of these failed experiments.
If the project is dormant, it is dormant. Anyone who wants to base their
business on a module that is not being maintained, understands the issue.
No action by the PMC is required until a someone wants to make it active
and even then, the sub-project leader can do that without the PMC by
adding new committers to the sub-project and updating the web site with
the new leader's name..
If the leader has completely left the OFBiz community (highly unlikely
but possible), then the PMC could put this new person or team in charge.
If the module has no community or people who care, why would the PMC
waste any time on it?
If there were PMC members who thought that this module was integral to
the success of OFBiz, I would expect them to be important contributors
to the sub-project.
You can join as many Apache projects and sub-projects as you have the
time and interest to support.
I hope that sub-projects will help attract new contributors by
increasing the scope of activities and adding focus to some of these
activities.
Currently, no one outside the PMC actually knows what the status of any
module is.
From what I gather, the state of any module in the "special" category
can not be determined easily unless you ask the dev list and even then,
you might get several opinions.
I also suspect that the OFBiz project is so big that it is hard to find
contributors who are willing and able to become committers.
This results in a small group who are not focused on any thing.
If the Project Management sub-project was to be set up, it would focus
on "Project Management" and even if several existing committers joined
the project, the only roadmap that would be uppermost in the Sub-PMC
would be how to make the best project management tools.
It would produce a very narrow roadmap, make very focused decisions
about support for various OFBiz versions and have a clear communication
policy about OFBiz Project Management.
It would draw in new people who need OFBiz to support project management
but have no interest in shopping carts or BOMs.
Regards
Scott
On 10/11/2014, at 3:35 pm, Ron Wheeler <rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>> wrote:
A very excellent discussion of the issues by Scott has prompted me to
document my thoughts.
Ron
On 07/11/2014 5:24 PM, Scott Gray wrote:
I still think you're putting the cart before the horse. I'm not
sure I could name any specialpurpose component that has the two or
three active contributors that I think would be necessary to sustain it.
It will become apparent when the team or person steps forward to
maintain it.
If you have only one or two and they go away then what happens to
any new comers looking to contribute?
They will have to ask the leader of the sub-project. If the
sub-project community is completely unresponsive, they could propose
to take over it.
Do we just make anyone who comes along a committer?
It is up to the sub-project to make that decision. Just the way
Apache leaves it up to OFBiz to decide who can commit.
The goal is to get these projects that have little or no current
support, set up in a way that they can find their own specialized
community that does not care to work on the framework.
Does the TLP PMC need to monitor a whole bunch of new mailing lists
and then support anyone who comes along in the hope they might be
able to become committers?
Not unless you care to stay on top of details. This is one of the
benefits of sub-projects.
You can reduce the flow through each list and only subscribe to stuff
you really need to follow, so you are only getting stuff that you
actually care about.
The archives are always available if you want to look up things after
the fact.
The sensible way to handle project management issues, is to set up an
OFBiz project mailing list that handles announcement or project news
that does not belong in the regular dev or user lists.
You can refer to the Apache project management pages for specific
suggestions about how Apache projects can handle this kind of activity.
If a component had no active committers how long would it be before
it broke completely because no one kept it updated?
Same as now. Soon.
Death of a module from natural causes ( no one caring) is not a bad
thing.
It just would be much easier to know when a module had died.
Currently, the OFBiz community has a hard time knowing what has died
and what is still valued.
If a security vulnerability is found then who will deal with it?
Same people who deal with it now if they actually care to keep
working on the sub-project.
New people who actually use the module would probably be very
interested in getting high priority issues fixed.
At least, you would know who "should" be fixing it.
Much better than the current state.
It would be up to the sub-project to establish its policies about
support for security (back-porting, supported versions), etc.
Without active committers the PMC would need to remain familiar with
the code in order to receive contributions and determine their
suitability for inclusion. Nothing would be different from now
except that the component would be less visible to us, more easily
forgotten and we'd have more infrastructure to deal with.
Why would the framework committers even care?
It is up to the sub-project to sort out their own code integrity issues.
They have the detailed knowledge and the subject matter expertise and
the motivation (they actually use it).
If the project dies, you don't have to do anything except post a note
on the sub-project web site announcing that it is no longer active
and that the PMC is looking for a new team.
If anyone else from the PMC thought that this sub-project was
important, they would have joined the sub-project in the first place.
At least everyone would know that the module was no longer active.
You can look only at the best case scenarios because you won't have
any responsibility to these sub-projects. The PMC however will
still have the burden to do anything that the sub-project committers
decide that they themselves no longer want to do.
Why? If the module is useless and no one cares, why would the PMC do
anything besides documenting the situation on the sub-project web page.
"This project is no longer maintained. The code is available 'as is'.
The last release of the module is know to work with version 13.07.
OFBiz would be pleased to hear of a team willing to continue working
on this module."
Stop thinking about it after that until an individual or a team shows up.
At what point will it be okay by you for us to kill it off? What
is it that currently gives you confidence that it won't happen very
quickly?
Yes, you can kill a project that no one is willing to work on or support.
At the moment it appears that several modules would have a hard time
surviving and should be killed.
From the discussion in this thread it appears that some are just
tests that failed.
This is better than the current case, wherein users have no idea
about what is active and what is dead and the PMC has to do a survey
of all users every time a decision about a dormant project has to be
made.
I think Jacopo's solution is the best to keep everyone happy
(including the vocal minority) but IMO the best approach would be to
remove the components from OFBiz altogether, set them up on github
or similar, ensure those who want to take ownership have the
required access and then advertise the existence of these special
purpose components from the OFBiz website. The components are then
free to stand or fall as they may. Should any actually survive and
thrive, then a subproject would seem like a good idea. It's my
opinion though that the vast majority of the components would go
dormant and I don't think it makes a difference whether it's as a
subproject or as an external project hosted elsewhere.
Removing them from Apache is a rather extreme approach that is likely
to lead to additional forking of the OFBiz project.
Apache has a well documented set of tools and processes for dealing
with modules or applications like this and there is no real value in
inventing some new process that is unlikely to be properly set up
given the amount of work being done in the supported bits of OFBiz.
I don't see any point of worrying at all about modules that have no
following.
We just need to be transparent about what is happening.
If they are supported, set up a sub-project that allows the
interested parties to work on them with as large a community as they
can attract.
They would not have to get mixed in with the framework project that
has a different set of concerns and requirements for committing.
They might not be committers to the framework or core ERP
If the projects are not supported, leave them as is and state clearly
on the project web page that these modules are not supported.
If there is a history of people working on them, using them in
production and caring, it would be nice to document that, in case
that someone finds them useful.
If they were tests that failed before being finished, perhaps moving
them to a section of "dead test" modules in the SCM would satisfy the
desire not to lose any code regardless of its uselessness as well as
making it clear that these modules are not functional and users
should think that the name of the module has anything to do with what
it will actually do.
Mixing them in with modules that are actively maintained is not helpful.
I hope that this helps.
Ron
Regards
Scott
On 8/11/2014, at 9:21 am, Ron Wheeler
<rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>> 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
<mailto:rwhee...@artifact-software.com>>
To: dev@ofbiz.apache.org <mailto: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
<mailto: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 <http://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
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Ron Wheeler
President
Artifact Software Inc
email:rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
