How to use ProjectMgr in 13.07

[gil portenseigne <gi...@nereide.fr>]

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



-- 

<www.nereide.fr>

	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 <http://www.nereide.fr>

Re: How to use ProjectMgr in 13.07

[Jacques Le Roux <ja...@les7arts.com>]

I'm all for it, good idea!

Jacques

Le 07/11/2014 13:11, Taher Alkhateeb a écrit :
> Hi Jacopo,
>
> Well thought and a good suggestion IMHO. Definitely a good middle ground
> solution that supports all components and keeps things alive
>
> Taher Alkhateeb
>
> Taher Alkhateeb
> On Nov 7, 2014 3:05 PM, "Jacopo Cappellato" <
> jacopo.cappellato@hotwaxmedia.com> wrote:
>
>> On Nov 7, 2014, at 12:36 PM, Jacques Le Roux <ja...@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.portenseigne@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
>>>>
>>

Re: How to use ProjectMgr in 13.07

[Taher Alkhateeb <sl...@gmail.com>]

Hi Jacopo,

Well thought and a good suggestion IMHO. Definitely a good middle ground
solution that supports all components and keeps things alive

Taher Alkhateeb

Taher Alkhateeb
On Nov 7, 2014 3:05 PM, "Jacopo Cappellato" <
jacopo.cappellato@hotwaxmedia.com> wrote:

> On Nov 7, 2014, at 12:36 PM, Jacques Le Roux <ja...@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.portenseigne@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
> >>
> >
>
>

Re: How to use ProjectMgr in 13.07

[Taher Alkhateeb <sl...@gmail.com>]

Hi Ron,

I really hope you are right on your vision for this. What you said makes
sense and needs some testing to affirm it.

Sign me up for the birt component as well as bootstrap for now if this goes
forward!

Taher Alkhateeb

Re: How to use ProjectMgr in 13.07

[Ron Wheeler <rw...@artifact-software.com>]

I am not sure that I fully understand the BIRT integration so I have 
some questions.

On 10/11/2014 5:40 AM, Taher Alkhateeb wrote:
> Hi everyone,
>
> This thread has been going on forever perhaps we are discussing things too
> generically. Let me try to put a concrete example based on the suggestions
> from everyone.
>
> Take the BIRT component as an example. What kind of work is needed for it?
> well you have the following:
>
> - Code to integrate it into the framework (BirtWorker.java,
> BirtFactory.java, integrating with controller, etc ...)
What skill is required here?
Is it clear to you what part of this should be in the core and what 
should be in the BIRT sub-project?
It seems to me that people who currently support BIRT would already have 
these skills and would be capable of teaching other Java coders enough 
about these modules to get them up to speed pretty quickly.


> - Code inside BIRT reports to generate the data specific for each report.
I think that this requires people who have BIRT expertise and have an 
understanding of the business data analysis process.
They would need to know how the data is made available from the 
framework but really do not need to know Java or the details of the 
database.
People with this profile would currently not be able to become 
committers to the OFBiz project and have no real BOF hope in OFBiz.
A sub-project should allow people with these skills to contribute with 
having to get a current committer to do something every time a report 
was created or changed

> - Code that can be generic (such as in a BIRT library) to unify all reports
> and minimize code repetition, standardize data preparation, etc...
This looks like a job for experts in business analysis who understands 
business reporting working with someone with Java coding and a good 
knowledge of the data access parts of the framework.
>
> So, maintaining and improving this component requires expertise in BIRT &
> also expertise in the framework itself. Now imagine the following scenario
>
> - The core committers decide to create a change to the framework
> - The change requires modification of the integration code, not the
> reporting specific code.
> - The integration code requires expertise in the internals of the framework
1)  the BIRT project has to make the decision to support this new version.
This would be a discussion on the BIRT dev mailing list.
If the changes are such that the BIRT project can not do this, BIRT 
would only be available for the current version version.
This is what happens now informally and no one is responsible for making 
this decision and it is not made public until after the new OFBiz 
release is issued and people find out that stuff no longer is included.

2) If it is to be done, then the people doing the work have to figure 
out when they will have it done.
It would be nice if they communicated the problem and proposed timeline 
to the PMC but they should certainly should let the BIRT user mailing 
list know that the BIRT module may be delayed if the work can not be 
done before the expected release of the new OFBiz core.
This at least lets companies depending on BIRT, know that they can not 
implement the upcoming version of OFBiz when it is released.

>
> Now without support and guidance of the core team nobody will be able to
> upgrade the component to remain compatible with trunk.
This is true. They will have to tell the BIRT team if they add new data 
fields or if they change the data model.
But at least the core team will have a knowledgeable group to talk to 
when contemplating changes to the data access that affects reporting.
The core team will be able to get a definitive answer about the impact 
on reporting of the proposed change without having to do the 
investigation themselves
> I am willing for
> example, to help as much as I can with this component. I am comfortable
> with BIRT and can provide contributions, but what about the integration
> code. Who maintains it?
Good question?
I think that you are assuming that no one who is currently committing 
the BIRT changes is willing to join the BIRT group.
This means that someone or some team needs to get up to speed on the 
BIRT integration in OFBiz.
This is a problem but it has a much smaller scope that what is required 
to become a committer on the entire framework and all the core modules 
which is the current state.
> Are there enough _experienced_ developers who are
> comfortable with the framework internals and yet want to support BIRT on
> the higher level (reports)?
That is the job of the team that wants to start a sub-project.
Is there enough interest to support the work and develop the expertise 
required to have BIRT in OFBiz?
Before starting a sub-project, you need to get a viable group together 
and work with the PMC to decide on the scope of the group.


> Sub-projects require available resources. As mentioned in the beginning of
> this thread OFBiz really has a problem with resources and a handful of
> people are doing the real heavy lifting. Without such individuals I see a
> small chance of any sub-projects to survive.
The goal is to add new contributors by lowering the bar to entry and 
attracting people who have no interest in the "heavy-lifting" of the 
framework or core modules but are passionate about reporting (or more 
reasonably have a real need for excellent reporting capabilities).

>   We are not the Linux Kernel
> project where you have developers left, right and center. If we were, we
> would have projects and sub-projects and sub-sub-sub-projects without a
> problem.
I think that it may be a chicken and egg problem.
Without sub-projects OFBiz is too big and complex to attract new 
contributors.
The core group is too small and are too busy to think about organizing 
the project to attract new contributors and to train and support the new 
people.

Take a look at other Apache projects that use sub-projects. They are not 
as big as the Linux community ( not as big as the OFBiz community in 
some cases) but they do use sub-projects to separate the work into teams 
that can attract people to work on specific areas.

> My 2 cents!
>
> Taher Alkhateeb
>
> On Mon, Nov 10, 2014 at 6:45 AM, Scott Gray <sc...@hotwaxmedia.com>
> 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 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.
>>
>> Particularly for security issues, the TLP PMC cannot simply ignore dormant
>> sub-projects, we have to take action if a report comes in.  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.
>>
>> Regards
>> Scott
>>
>> On 10/11/2014, at 3:35 pm, Ron Wheeler <rw...@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 <rw...@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" <rw...@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.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
>>>>>>>>>> <ja...@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
>>>>>>>>>>>>>>> <gi...@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: rwheeler@artifact-software.com
>>>>> skype: ronaldmwheeler
>>>>> phone: 866-970-2435, ext 102
>>>>>
>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>


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

Re: How to use ProjectMgr in 13.07

[Taher Alkhateeb <sl...@gmail.com>]

Hi everyone,

This thread has been going on forever perhaps we are discussing things too
generically. Let me try to put a concrete example based on the suggestions
from everyone.

Take the BIRT component as an example. What kind of work is needed for it?
well you have the following:

- Code to integrate it into the framework (BirtWorker.java,
BirtFactory.java, integrating with controller, etc ...)
- Code inside BIRT reports to generate the data specific for each report.
- Code that can be generic (such as in a BIRT library) to unify all reports
and minimize code repetition, standardize data preparation, etc...

So, maintaining and improving this component requires expertise in BIRT &
also expertise in the framework itself. Now imagine the following scenario

- The core committers decide to create a change to the framework
- The change requires modification of the integration code, not the
reporting specific code.
- The integration code requires expertise in the internals of the framework

Now without support and guidance of the core team nobody will be able to
upgrade the component to remain compatible with trunk. I am willing for
example, to help as much as I can with this component. I am comfortable
with BIRT and can provide contributions, but what about the integration
code. Who maintains it? Are there enough _experienced_ developers who are
comfortable with the framework internals and yet want to support BIRT on
the higher level (reports)?

Sub-projects require available resources. As mentioned in the beginning of
this thread OFBiz really has a problem with resources and a handful of
people are doing the real heavy lifting. Without such individuals I see a
small chance of any sub-projects to survive. We are not the Linux Kernel
project where you have developers left, right and center. If we were, we
would have projects and sub-projects and sub-sub-sub-projects without a
problem.

My 2 cents!

Taher Alkhateeb

On Mon, Nov 10, 2014 at 6:45 AM, Scott Gray <sc...@hotwaxmedia.com>
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 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.
>
> Particularly for security issues, the TLP PMC cannot simply ignore dormant
> sub-projects, we have to take action if a report comes in.  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.
>
> Regards
> Scott
>
> On 10/11/2014, at 3:35 pm, Ron Wheeler <rw...@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 <rw...@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" <rw...@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.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
> >>>>>>>> <ja...@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
> >>>>>>>>>>>>> <gi...@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: rwheeler@artifact-software.com
> >>> skype: ronaldmwheeler
> >>> phone: 866-970-2435, ext 102
> >>>
> >>
> >
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwheeler@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
>
>

Re: How to use ProjectMgr in 13.07

[Ron Wheeler <rw...@artifact-software.com>]

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 <rwheeler@artifact-software.com 
> <ma...@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 
>>> <rwheeler@artifact-software.com 
>>> <ma...@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" <rwheeler@artifact-software.com 
>>>>> <ma...@artifact-software.com>>
>>>>> To: dev@ofbiz.apache.org <ma...@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.crum@sandglass-software.com 
>>>>>> <ma...@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
>>>>>>>>> <ja...@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
>>>>>>>>>>>>>> <gi...@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: rwheeler@artifact-software.com 
>>>> <ma...@artifact-software.com>
>>>> skype: ronaldmwheeler
>>>> phone: 866-970-2435, ext 102
>>>>
>>>
>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email:rwheeler@artifact-software.com 
>> <ma...@artifact-software.com>
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>


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

Re: How to use ProjectMgr in 13.07

[Scott Gray <sc...@hotwaxmedia.com>]

>> 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 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.

Particularly for security issues, the TLP PMC cannot simply ignore dormant sub-projects, we have to take action if a report comes in.  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.

Regards
Scott

On 10/11/2014, at 3:35 pm, Ron Wheeler <rw...@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 <rw...@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" <rw...@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 <ad...@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
>>>>>>>> <ja...@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
>>>>>>>>>>>>> <gi...@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: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102

Re: How to use ProjectMgr in 13.07

[Ron Wheeler <rw...@artifact-software.com>]

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 <rw...@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" <rw...@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 <ad...@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
>>>>>>> <ja...@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
>>>>>>>>>>>> <gi...@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: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>


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

Re: How to use ProjectMgr in 13.07

[Scott Gray <sc...@hotwaxmedia.com>]

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.  
If you have only one or two and they go away then what happens to any new comers looking to contribute?  
Do we just make anyone who comes along a committer?  
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?
If a component had no active committers how long would it be before it broke completely because no one kept it updated?
If a security vulnerability is found then who will deal with it?

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.

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.  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?

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.

Regards
Scott

On 8/11/2014, at 9:21 am, Ron Wheeler <rw...@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" <rw...@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 <ad...@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
>>>>>> <ja...@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
>>>>>>>>>>> <gi...@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: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 

Re: How to use ProjectMgr in 13.07

[Adrian Crum <ad...@sandglass-software.com>]

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" <rw...@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
>>> <ad...@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
>>>>>> <ja...@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
>>>>>>>>>>> <gi...@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
>>
>
>

Re: How to use ProjectMgr in 13.07

[Ron Wheeler <rw...@artifact-software.com>]

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" <rw...@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 <ad...@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
>>>>> <ja...@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
>>>>>>>>>> <gi...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: How to use ProjectMgr in 13.07

[Taher Alkhateeb <sl...@gmail.com>]

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" <rw...@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 <ad...@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 
>>>> <ja...@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 
>>>>>>>>> <gi...@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: rwheeler@artifact-software.com 
skype: ronaldmwheeler 
phone: 866-970-2435, ext 102 

Re: How to use ProjectMgr in 13.07

[Ron Wheeler <rw...@artifact-software.com>]

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 <ad...@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
>>>> <ja...@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
>>>>>>>>> <gi...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: How to use ProjectMgr in 13.07

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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 <ad...@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
>>> <ja...@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
>>>>>>>> <gi...@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
>>> 
>> 
>> 

Re: How to use ProjectMgr in 13.07

[Julien NICOLAS <ju...@nomaka.fr>]

Hi All,

I agree that hot-deploy component don't have to be installed with the 
core project by default. But in the other hand it could be interesting 
to be aware of those projects.

When I read this topics, it seems matching with an extension manager...

French community is working on this extension manager project maybe it 
could be the way to split specific OFBiz extension and the core project ?

Am I wrong ?

Julien.

Le 07/11/2014 17:32, Adrian Crum a écrit :
> 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
>>> <ja...@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
>>>>>>>> <gi...@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
>>>
>>
>>

Re: How to use ProjectMgr in 13.07

[Adrian Crum <ad...@sandglass-software.com>]

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
>> <ja...@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
>>>>>>> <gi...@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
>>
>
>

Re: How to use ProjectMgr in 13.07

[Ron Wheeler <rw...@artifact-software.com>]

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 <ja...@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 <gi...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: How to use ProjectMgr in 13.07

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Nov 7, 2014, at 12:36 PM, Jacques Le Roux <ja...@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 <gi...@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
>>  
> 

Re: How to use ProjectMgr in 13.07

[Taher Alkhateeb <sl...@gmail.com>]

Hi Jacques,

Birt is definitely important for us

Taher Alkhateeb
On Nov 7, 2014 2:40 PM, "Jacques Le Roux" <ja...@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, 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
> <gi...@nereide.fr> <gi...@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
>
>
>
>
>
> --
>
>  <http://www.nereide.fr>
>  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
>
>
>
>
>

Re: How to use ProjectMgr in 13.07

[Jacques Le Roux <ja...@les7arts.com>]

This will no longer work for some components (scrum for instance)

I believe we could be reintroduce some specialpurpose component in next release, 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 <gi...@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
>>>
>>>
>
>
> -- 
>
> <www.nereide.fr>
>
> 	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 <http://www.nereide.fr>
>

Re: How to use ProjectMgr in 13.07

[gil portenseigne <gi...@nereide.fr>]

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 
>>> <gi...@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
>>
>>


-- 

<www.nereide.fr>

	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 <http://www.nereide.fr>

Re: How to use ProjectMgr in 13.07

[Jacques Le Roux <ja...@les7arts.com>]

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 <gi...@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
>
>

Re: How to use ProjectMgr in 13.07

[gil portenseigne <gi...@nereide.fr>]

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 <gi...@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
>>   

Re: How to use ProjectMgr in 13.07

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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 <gi...@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
>