subject:"Re\: \[VOTE\] PROJECTMGR in upcoming release"

Ron,

The PROJECTMGR does function within the 13.x branch. We monitor this
closely. And you can see for your self, as it is included in the
demo-stable environment (
http://demo-stable-ofbiz.apache.org/projectmgr/control/main).

We monitor also apps/components as SCRUM, HUMANRES and MARKETING (SFA 
Mass comm). These solutions fall in the same category as PROJECTMGR, with
few changes of the past 2 years and few to none test cases.

We should not remove apps and components that rapidly from the solution
portfolio of OFBiz, merely because these don't receive a lot of love from
the active participants in this community. I expect that a lot of our
community members do focus on the e-commerce solution and functionalities
first. But it is the strength of any ERP solution (and of the open source
ones in particular) to cater to as many industry sectors and business
scenarios as possible. Marketing OFBiz as such by tweets and blog posts do
help adoption and attraction of new contributors.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Fri, Oct 3, 2014 at 8:50 AM, Ron Wheeler rwhee...@artifact-software.com
wrote:

 Are there a lot of outstanding JIRA issues that users want fixed?
 It is not inconceivable that a module works as required.
 I am not sure that measuring the usefulness of a module by the number of
 bugs or deficiencies found recently is accurate.

 It seems to have been tested with the trunk as the core OFBiz has evolved.

 It appears that it may need some testing with the ccore 13.07.01 Release
 before PROJECTMGR can be either said to work as is with 13.07.01 or
 released as a new version of PROJECTMGR that does work with 13.07.01.

 If there was a sub-project with a following, there would be a group of
 people who want it to work and would be prepared to do what was required to
 keep the module functioning.
 It would be quite clear to the people interested in PROJECTMGR that it was
 their responsibility to make sure that it was functional with 13.07.01.
 Currently, the connection between individual modules and the people who
 care is a bit fuzzy and has resulted in decisions being taken by people who
 do not have a real interest in the particular modules that are being
 dropped. They have no way to connect with the interested parties or even to
 be sure about who they are.
 One of the values of sub-projects is that you capture groups that have a
 narrow interest in particular areas but are not able to commit to the
 entire project.
 The people working on the release of the core also have a clear project
 management group in each sub-project to consult when core functionality
 will affect individual modules or when planning a release and want to let
 the sub-project teams know that they must take some action in order to keep
 their module functional.

 It is not inconceivable that some sub-projects will die due to lack of
 interest.
 PROJECTMGR seems to have some life in it but without a formal sub-project
 structure it is hard to judge except from ML discussions and recent
 activity.

 Ron


 On 02/10/2014 3:02 PM, Scott Gray wrote:

 Surely the first step in considering a specialized component for
 sub-project creation would be the level of activity surrounding the
 component?

 Looking at the history of the projectmgr component I see 12 commits in
 the last TWO years 8 of which were global changes that coincidentally
 happened to touch on that component (translation work, global refactorings
 etc.).  This leaves only 4 commits specific to the component and even those
 are minor UI adjustments.

 To be considered as a potential sub-project I would expect to see a hive
 of activity around that component with contributors specializing in solid
 contributions to further enhance it.  Build it and they will come is not
 a valid approach to sub-project creation.

 If this component is so important to some of you, why are you not
 contributing to its enhancement?

 Regards
 Scott

 On 3/10/2014, at 2:56 am, Ron Wheeler rwhee...@artifact-software.com
 wrote:

  Of course, I see a lot of benefit in the Apache approach of sub-projects
 but perhaps the current group of committers should take some time to
 consider this and talk to the Apache Mentors assigned to the project as
 well as some of the project chairpersons from projects where sub-projects
 are in use.

 One of the advantages of being an Apache project is that there are many
 things for which there is an Apache Way and there are people in the
 broader Apache community that can provide information and guidance.

 To Jacopo's point about trust.
 I may trust someone to do one thing but not another.
 I may trust someone with a critical task that I would not entrust to
 another person who might be technically capable of doing it.

 As a project manager, I may trust someone to work on a particular part
 of an application but not

Re: [VOTE] PROJECTMGR in upcoming release

Ron, all,

Were you aware that the demo-stable environment is based on the 13.x
branch, with inclusions of  BIRT, PROJECTMGR, SCRUM, and other components
in the Special Purpose stack in trunk. That shows that all of these
components will function within the 13.07.01 release.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Fri, Oct 3, 2014 at 9:53 AM, Pierre Smits pierre.sm...@gmail.com wrote:

 Ron,

 The PROJECTMGR does function within the 13.x branch. We monitor this
 closely. And you can see for your self, as it is included in the
 demo-stable environment (
 http://demo-stable-ofbiz.apache.org/projectmgr/control/main).

 We monitor also apps/components as SCRUM, HUMANRES and MARKETING (SFA 
 Mass comm). These solutions fall in the same category as PROJECTMGR, with
 few changes of the past 2 years and few to none test cases.

 We should not remove apps and components that rapidly from the solution
 portfolio of OFBiz, merely because these don't receive a lot of love from
 the active participants in this community. I expect that a lot of our
 community members do focus on the e-commerce solution and functionalities
 first. But it is the strength of any ERP solution (and of the open source
 ones in particular) to cater to as many industry sectors and business
 scenarios as possible. Marketing OFBiz as such by tweets and blog posts do
 help adoption and attraction of new contributors.

 Regards,

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Fri, Oct 3, 2014 at 8:50 AM, Ron Wheeler 
 rwhee...@artifact-software.com wrote:

 Are there a lot of outstanding JIRA issues that users want fixed?
 It is not inconceivable that a module works as required.
 I am not sure that measuring the usefulness of a module by the number of
 bugs or deficiencies found recently is accurate.

 It seems to have been tested with the trunk as the core OFBiz has evolved.

 It appears that it may need some testing with the ccore 13.07.01 Release
 before PROJECTMGR can be either said to work as is with 13.07.01 or
 released as a new version of PROJECTMGR that does work with 13.07.01.

 If there was a sub-project with a following, there would be a group of
 people who want it to work and would be prepared to do what was required to
 keep the module functioning.
 It would be quite clear to the people interested in PROJECTMGR that it
 was their responsibility to make sure that it was functional with 13.07.01.
 Currently, the connection between individual modules and the people who
 care is a bit fuzzy and has resulted in decisions being taken by people who
 do not have a real interest in the particular modules that are being
 dropped. They have no way to connect with the interested parties or even to
 be sure about who they are.
 One of the values of sub-projects is that you capture groups that have a
 narrow interest in particular areas but are not able to commit to the
 entire project.
 The people working on the release of the core also have a clear project
 management group in each sub-project to consult when core functionality
 will affect individual modules or when planning a release and want to let
 the sub-project teams know that they must take some action in order to keep
 their module functional.

 It is not inconceivable that some sub-projects will die due to lack of
 interest.
 PROJECTMGR seems to have some life in it but without a formal sub-project
 structure it is hard to judge except from ML discussions and recent
 activity.

 Ron


 On 02/10/2014 3:02 PM, Scott Gray wrote:

 Surely the first step in considering a specialized component for
 sub-project creation would be the level of activity surrounding the
 component?

 Looking at the history of the projectmgr component I see 12 commits in
 the last TWO years 8 of which were global changes that coincidentally
 happened to touch on that component (translation work, global refactorings
 etc.).  This leaves only 4 commits specific to the component and even those
 are minor UI adjustments.

 To be considered as a potential sub-project I would expect to see a hive
 of activity around that component with contributors specializing in solid
 contributions to further enhance it.  Build it and they will come is not
 a valid approach to sub-project creation.

 If this component is so important to some of you, why are you not
 contributing to its enhancement?

 Regards
 Scott

 On 3/10/2014, at 2:56 am, Ron Wheeler rwhee...@artifact-software.com
 wrote:

  Of course, I see a lot of benefit in the Apache approach of
 sub-projects but perhaps the current group of committers should take some
 time to consider this and talk to the Apache Mentors assigned to the
 project as well as some of the project chairpersons from projects where

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-03 Thread Scott Gray

 Currently, the connection between individual modules and the people who care 
 is a bit fuzzy and has resulted in decisions being taken by people who do not 
 have a real interest in the particular modules that are being dropped. They 
 have no way to connect with the interested parties or even to be sure about 
 who they are.
 One of the values of sub-projects is that you capture groups that have a 
 narrow interest in particular areas but are not able to commit to the entire 
 project.

We have mailing lists and jira to gauge interest in a specific component.  Code 
contributions in particular are very useful in determining interest, unless 
you're suggesting that the component is perfect and no further work is 
required.  Everything in OFBiz has room for improvement and a lack of 
contributions is very much an indicator of a lack of interest in my opinion and 
experience with this project.

It doesn't make any sense to create sub-projects in the hope that someone might 
show up and start community building.  The ASF doesn't work that way for 
top-level projects and by the DB Project link you sent earlier implies they 
don't work that way for sub-projects either.  A community must exist around a 
given component before it can have any hope of standing on its own.

Regards
Scott

On 3/10/2014, at 7:50 pm, Ron Wheeler rwhee...@artifact-software.com wrote:

 Are there a lot of outstanding JIRA issues that users want fixed?
 It is not inconceivable that a module works as required.
 I am not sure that measuring the usefulness of a module by the number of bugs 
 or deficiencies found recently is accurate.
 
 It seems to have been tested with the trunk as the core OFBiz has evolved.
 
 It appears that it may need some testing with the ccore 13.07.01 Release 
 before PROJECTMGR can be either said to work as is with 13.07.01 or released 
 as a new version of PROJECTMGR that does work with 13.07.01.
 
 If there was a sub-project with a following, there would be a group of people 
 who want it to work and would be prepared to do what was required to keep the 
 module functioning.
 It would be quite clear to the people interested in PROJECTMGR that it was 
 their responsibility to make sure that it was functional with 13.07.01.
 Currently, the connection between individual modules and the people who care 
 is a bit fuzzy and has resulted in decisions being taken by people who do not 
 have a real interest in the particular modules that are being dropped. They 
 have no way to connect with the interested parties or even to be sure about 
 who they are.
 One of the values of sub-projects is that you capture groups that have a 
 narrow interest in particular areas but are not able to commit to the entire 
 project.
 The people working on the release of the core also have a clear project 
 management group in each sub-project to consult when core functionality will 
 affect individual modules or when planning a release and want to let the 
 sub-project teams know that they must take some action in order to keep their 
 module functional.
 
 It is not inconceivable that some sub-projects will die due to lack of 
 interest.
 PROJECTMGR seems to have some life in it but without a formal sub-project 
 structure it is hard to judge except from ML discussions and recent activity.
 
 Ron
 
 On 02/10/2014 3:02 PM, Scott Gray wrote:
 Surely the first step in considering a specialized component for sub-project 
 creation would be the level of activity surrounding the component?
 
 Looking at the history of the projectmgr component I see 12 commits in the 
 last TWO years 8 of which were global changes that coincidentally happened 
 to touch on that component (translation work, global refactorings etc.).  
 This leaves only 4 commits specific to the component and even those are 
 minor UI adjustments.
 
 To be considered as a potential sub-project I would expect to see a hive of 
 activity around that component with contributors specializing in solid 
 contributions to further enhance it.  Build it and they will come is not a 
 valid approach to sub-project creation.
 
 If this component is so important to some of you, why are you not 
 contributing to its enhancement?
 
 Regards
 Scott
 
 On 3/10/2014, at 2:56 am, Ron Wheeler rwhee...@artifact-software.com wrote:
 
 Of course, I see a lot of benefit in the Apache approach of sub-projects 
 but perhaps the current group of committers should take some time to 
 consider this and talk to the Apache Mentors assigned to the project as 
 well as some of the project chairpersons from projects where sub-projects 
 are in use.
 
 One of the advantages of being an Apache project is that there are many 
 things for which there is an Apache Way and there are people in the 
 broader Apache community that can provide information and guidance.
 
 To Jacopo's point about trust.
 I may trust someone to do one thing but not another.
 I may trust someone with a critical task that I would not

Re: [VOTE] PROJECTMGR in upcoming release

That does work for other top level projects under the ASF umbrella.
Recently a discussion is started in the mailing list of Apache Directory
server to adopt a new - external - component  as a sub project (the do
everything in sub projects), that has only 1 committer and 1 contributor.
There you also can't talk about having a great adoption within the
community of that project, because it isn't there yet. But there are
sentiments in favour of it, as it will expand the feature set of the works
of the project and the visibility of the project itself.

When you look at the CouchDb project, you'll see that they have dedicated
mailing lists for various themes. You'll see that anything is possible
under the ASF umbrella when you take a closer look.

The Apache way is not to restricting people willing to do stuff, but to
enable them. And often you need to promote to get the attention of
contributors. Downplaying etc. does the opposite.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Fri, Oct 3, 2014 at 10:27 AM, Scott Gray scott.g...@hotwaxmedia.com
wrote:

  Currently, the connection between individual modules and the people who
 care is a bit fuzzy and has resulted in decisions being taken by people who
 do not have a real interest in the particular modules that are being
 dropped. They have no way to connect with the interested parties or even to
 be sure about who they are.
  One of the values of sub-projects is that you capture groups that have a
 narrow interest in particular areas but are not able to commit to the
 entire project.

 We have mailing lists and jira to gauge interest in a specific component.
 Code contributions in particular are very useful in determining interest,
 unless you're suggesting that the component is perfect and no further work
 is required.  Everything in OFBiz has room for improvement and a lack of
 contributions is very much an indicator of a lack of interest in my opinion
 and experience with this project.

 It doesn't make any sense to create sub-projects in the hope that someone
 might show up and start community building.  The ASF doesn't work that way
 for top-level projects and by the DB Project link you sent earlier implies
 they don't work that way for sub-projects either.  A community must exist
 around a given component before it can have any hope of standing on its own.

 Regards
 Scott

 On 3/10/2014, at 7:50 pm, Ron Wheeler rwhee...@artifact-software.com
 wrote:

  Are there a lot of outstanding JIRA issues that users want fixed?
  It is not inconceivable that a module works as required.
  I am not sure that measuring the usefulness of a module by the number of
 bugs or deficiencies found recently is accurate.
 
  It seems to have been tested with the trunk as the core OFBiz has
 evolved.
 
  It appears that it may need some testing with the ccore 13.07.01 Release
 before PROJECTMGR can be either said to work as is with 13.07.01 or
 released as a new version of PROJECTMGR that does work with 13.07.01.
 
  If there was a sub-project with a following, there would be a group of
 people who want it to work and would be prepared to do what was required to
 keep the module functioning.
  It would be quite clear to the people interested in PROJECTMGR that it
 was their responsibility to make sure that it was functional with 13.07.01.
  Currently, the connection between individual modules and the people who
 care is a bit fuzzy and has resulted in decisions being taken by people who
 do not have a real interest in the particular modules that are being
 dropped. They have no way to connect with the interested parties or even to
 be sure about who they are.
  One of the values of sub-projects is that you capture groups that have a
 narrow interest in particular areas but are not able to commit to the
 entire project.
  The people working on the release of the core also have a clear project
 management group in each sub-project to consult when core functionality
 will affect individual modules or when planning a release and want to let
 the sub-project teams know that they must take some action in order to keep
 their module functional.
 
  It is not inconceivable that some sub-projects will die due to lack of
 interest.
  PROJECTMGR seems to have some life in it but without a formal
 sub-project structure it is hard to judge except from ML discussions and
 recent activity.
 
  Ron
 
  On 02/10/2014 3:02 PM, Scott Gray wrote:
  Surely the first step in considering a specialized component for
 sub-project creation would be the level of activity surrounding the
 component?
 
  Looking at the history of the projectmgr component I see 12 commits in
 the last TWO years 8 of which were global changes that coincidentally
 happened to touch on that component (translation work, global refactorings
 etc.).  This leaves only 4 commits specific to the

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-03 Thread Jacques Le Roux



Le 03/10/2014 09:53, Pierre Smits a écrit :

Ron,

The PROJECTMGR does function within the 13.x branch. We monitor this
closely. And you can see for your self, as it is included in the
demo-stable environment (
http://demo-stable-ofbiz.apache.org/projectmgr/control/main).


Yes, I did that indeed. See tools\demo-backup\branch13.7-demo.patch if you want 
to do the same in your own trunk instance
BTW I will soon completely restart each demo instance every day (ie clean the 
data and rebuild from scratch)

Jacques


We monitor also apps/components as SCRUM, HUMANRES and MARKETING (SFA 
Mass comm). These solutions fall in the same category as PROJECTMGR, with
few changes of the past 2 years and few to none test cases.

We should not remove apps and components that rapidly from the solution
portfolio of OFBiz, merely because these don't receive a lot of love from
the active participants in this community. I expect that a lot of our
community members do focus on the e-commerce solution and functionalities
first. But it is the strength of any ERP solution (and of the open source
ones in particular) to cater to as many industry sectors and business
scenarios as possible. Marketing OFBiz as such by tweets and blog posts do
help adoption and attraction of new contributors.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Fri, Oct 3, 2014 at 8:50 AM, Ron Wheeler rwhee...@artifact-software.com
wrote:


Are there a lot of outstanding JIRA issues that users want fixed?
It is not inconceivable that a module works as required.
I am not sure that measuring the usefulness of a module by the number of
bugs or deficiencies found recently is accurate.

It seems to have been tested with the trunk as the core OFBiz has evolved.

It appears that it may need some testing with the ccore 13.07.01 Release
before PROJECTMGR can be either said to work as is with 13.07.01 or
released as a new version of PROJECTMGR that does work with 13.07.01.

If there was a sub-project with a following, there would be a group of
people who want it to work and would be prepared to do what was required to
keep the module functioning.
It would be quite clear to the people interested in PROJECTMGR that it was
their responsibility to make sure that it was functional with 13.07.01.
Currently, the connection between individual modules and the people who
care is a bit fuzzy and has resulted in decisions being taken by people who
do not have a real interest in the particular modules that are being
dropped. They have no way to connect with the interested parties or even to
be sure about who they are.
One of the values of sub-projects is that you capture groups that have a
narrow interest in particular areas but are not able to commit to the
entire project.
The people working on the release of the core also have a clear project
management group in each sub-project to consult when core functionality
will affect individual modules or when planning a release and want to let
the sub-project teams know that they must take some action in order to keep
their module functional.

It is not inconceivable that some sub-projects will die due to lack of
interest.
PROJECTMGR seems to have some life in it but without a formal sub-project
structure it is hard to judge except from ML discussions and recent
activity.

Ron


On 02/10/2014 3:02 PM, Scott Gray wrote:


Surely the first step in considering a specialized component for
sub-project creation would be the level of activity surrounding the
component?

Looking at the history of the projectmgr component I see 12 commits in
the last TWO years 8 of which were global changes that coincidentally
happened to touch on that component (translation work, global refactorings
etc.).  This leaves only 4 commits specific to the component and even those
are minor UI adjustments.

To be considered as a potential sub-project I would expect to see a hive
of activity around that component with contributors specializing in solid
contributions to further enhance it.  Build it and they will come is not
a valid approach to sub-project creation.

If this component is so important to some of you, why are you not
contributing to its enhancement?

Regards
Scott

On 3/10/2014, at 2:56 am, Ron Wheeler rwhee...@artifact-software.com
wrote:

  Of course, I see a lot of benefit in the Apache approach of sub-projects

but perhaps the current group of committers should take some time to
consider this and talk to the Apache Mentors assigned to the project as
well as some of the project chairpersons from projects where sub-projects
are in use.

One of the advantages of being an Apache project is that there are many
things for which there is an Apache Way and there are people in the
broader Apache community that can provide information and guidance.

To Jacopo's point about trust.
I may trust someone to do one thing but not

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-03 Thread Scott Gray

Do you have a link to the discussion they had Pierre?  It would be interesting 
to read more of the context.  Although even with one active contributor, it 
sounds like it is still doing better than our projectmgr component which has 
none.

And yes it is quite true that projects have a decent amount of flexibility in 
what they can and cannot do.  I was simply saying that community diversity is a 
major factor in considering top-level project proposals and commonly (but 
apparently not always) in sub-projects as well, I think the reasons for this 
are self explanatory but yes exceptions are obviously also made sometimes.

I just simply don't believe that our current approach could be so inhibiting 
that the component just sits there with no consistently active contributors.  
Maybe the component needs more marketing?  Perhaps those with an interest in 
the component could consider writing some blog posts or mentioning it in 
relevant social media, forums, mailing lists etc., writing additional 
documentation may help too.  Perhaps you (Pierre) could consider contributing 
some of the customizations you mentioned having made.  My point is that there 
is much that could be done by anyone in the community who cares enough to do 
it.  Not every problem can be laid solely at the feet of the PMC (IMO very few 
actually can, but we obviously disagree on that).

Regards
Scott

On 3/10/2014, at 9:45 pm, Pierre Smits pierre.sm...@gmail.com wrote:

 That does work for other top level projects under the ASF umbrella.
 Recently a discussion is started in the mailing list of Apache Directory
 server to adopt a new - external - component  as a sub project (the do
 everything in sub projects), that has only 1 committer and 1 contributor.
 There you also can't talk about having a great adoption within the
 community of that project, because it isn't there yet. But there are
 sentiments in favour of it, as it will expand the feature set of the works
 of the project and the visibility of the project itself.
 
 When you look at the CouchDb project, you'll see that they have dedicated
 mailing lists for various themes. You'll see that anything is possible
 under the ASF umbrella when you take a closer look.
 
 The Apache way is not to restricting people willing to do stuff, but to
 enable them. And often you need to promote to get the attention of
 contributors. Downplaying etc. does the opposite.
 
 Regards,
 
 Pierre Smits
 
 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com
 
 On Fri, Oct 3, 2014 at 10:27 AM, Scott Gray scott.g...@hotwaxmedia.com
 wrote:
 
 Currently, the connection between individual modules and the people who
 care is a bit fuzzy and has resulted in decisions being taken by people who
 do not have a real interest in the particular modules that are being
 dropped. They have no way to connect with the interested parties or even to
 be sure about who they are.
 One of the values of sub-projects is that you capture groups that have a
 narrow interest in particular areas but are not able to commit to the
 entire project.
 
 We have mailing lists and jira to gauge interest in a specific component.
 Code contributions in particular are very useful in determining interest,
 unless you're suggesting that the component is perfect and no further work
 is required.  Everything in OFBiz has room for improvement and a lack of
 contributions is very much an indicator of a lack of interest in my opinion
 and experience with this project.
 
 It doesn't make any sense to create sub-projects in the hope that someone
 might show up and start community building.  The ASF doesn't work that way
 for top-level projects and by the DB Project link you sent earlier implies
 they don't work that way for sub-projects either.  A community must exist
 around a given component before it can have any hope of standing on its own.
 
 Regards
 Scott
 
 On 3/10/2014, at 7:50 pm, Ron Wheeler rwhee...@artifact-software.com
 wrote:
 
 Are there a lot of outstanding JIRA issues that users want fixed?
 It is not inconceivable that a module works as required.
 I am not sure that measuring the usefulness of a module by the number of
 bugs or deficiencies found recently is accurate.
 
 It seems to have been tested with the trunk as the core OFBiz has
 evolved.
 
 It appears that it may need some testing with the ccore 13.07.01 Release
 before PROJECTMGR can be either said to work as is with 13.07.01 or
 released as a new version of PROJECTMGR that does work with 13.07.01.
 
 If there was a sub-project with a following, there would be a group of
 people who want it to work and would be prepared to do what was required to
 keep the module functioning.
 It would be quite clear to the people interested in PROJECTMGR that it
 was their responsibility to make sure that it was functional with 13.07.01.
 Currently, the connection between individual

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-03 Thread Jacques Le Roux



Le 03/10/2014 11:48, Jacques Le Roux a écrit :


Le 03/10/2014 09:53, Pierre Smits a écrit :

Ron,

The PROJECTMGR does function within the 13.x branch. We monitor this
closely. And you can see for your self, as it is included in the
demo-stable environment (
http://demo-stable-ofbiz.apache.org/projectmgr/control/main).


Yes, I did that indeed. See tools\demo-backup\branch13.7-demo.patch if you want 
to do the same in your own trunk instance


Ha forgot, this has been questioned by Jacopo recently 
http://markmail.org/message/xc4suz4pigo3m6z7

Jacques


BTW I will soon completely restart each demo instance every day (ie clean the 
data and rebuild from scratch)

Jacques


We monitor also apps/components as SCRUM, HUMANRES and MARKETING (SFA 
Mass comm). These solutions fall in the same category as PROJECTMGR, with
few changes of the past 2 years and few to none test cases.

We should not remove apps and components that rapidly from the solution
portfolio of OFBiz, merely because these don't receive a lot of love from
the active participants in this community. I expect that a lot of our
community members do focus on the e-commerce solution and functionalities
first. But it is the strength of any ERP solution (and of the open source
ones in particular) to cater to as many industry sectors and business
scenarios as possible. Marketing OFBiz as such by tweets and blog posts do
help adoption and attraction of new contributors.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Fri, Oct 3, 2014 at 8:50 AM, Ron Wheeler rwhee...@artifact-software.com
wrote:


Are there a lot of outstanding JIRA issues that users want fixed?
It is not inconceivable that a module works as required.
I am not sure that measuring the usefulness of a module by the number of
bugs or deficiencies found recently is accurate.

It seems to have been tested with the trunk as the core OFBiz has evolved.

It appears that it may need some testing with the ccore 13.07.01 Release
before PROJECTMGR can be either said to work as is with 13.07.01 or
released as a new version of PROJECTMGR that does work with 13.07.01.

If there was a sub-project with a following, there would be a group of
people who want it to work and would be prepared to do what was required to
keep the module functioning.
It would be quite clear to the people interested in PROJECTMGR that it was
their responsibility to make sure that it was functional with 13.07.01.
Currently, the connection between individual modules and the people who
care is a bit fuzzy and has resulted in decisions being taken by people who
do not have a real interest in the particular modules that are being
dropped. They have no way to connect with the interested parties or even to
be sure about who they are.
One of the values of sub-projects is that you capture groups that have a
narrow interest in particular areas but are not able to commit to the
entire project.
The people working on the release of the core also have a clear project
management group in each sub-project to consult when core functionality
will affect individual modules or when planning a release and want to let
the sub-project teams know that they must take some action in order to keep
their module functional.

It is not inconceivable that some sub-projects will die due to lack of
interest.
PROJECTMGR seems to have some life in it but without a formal sub-project
structure it is hard to judge except from ML discussions and recent
activity.

Ron


On 02/10/2014 3:02 PM, Scott Gray wrote:


Surely the first step in considering a specialized component for
sub-project creation would be the level of activity surrounding the
component?

Looking at the history of the projectmgr component I see 12 commits in
the last TWO years 8 of which were global changes that coincidentally
happened to touch on that component (translation work, global refactorings
etc.).  This leaves only 4 commits specific to the component and even those
are minor UI adjustments.

To be considered as a potential sub-project I would expect to see a hive
of activity around that component with contributors specializing in solid
contributions to further enhance it.  Build it and they will come is not
a valid approach to sub-project creation.

If this component is so important to some of you, why are you not
contributing to its enhancement?

Regards
Scott

On 3/10/2014, at 2:56 am, Ron Wheeler rwhee...@artifact-software.com
wrote:

  Of course, I see a lot of benefit in the Apache approach of sub-projects

but perhaps the current group of committers should take some time to
consider this and talk to the Apache Mentors assigned to the project as
well as some of the project chairpersons from projects where sub-projects
are in use.

One of the advantages of being an Apache project is that there are many
things for which there is an Apache Way and there are

Re: [VOTE] PROJECTMGR in upcoming release

Scott,

All regarding the addition in the dev mailing list of the Directory project
can be found here:
http://directory.markmail.org/search/?q=+list%3Aorg.apache.directory.dev+fortress

You are right in the aspect that more marketing needs to be done with
respect of the applicability of OFBiz in the various industry sectors and
business scenarios. I (and others) have been doing it more in relation to
the upcoming ApacheCon EU event via twitter and other means. And the effect
of that can be measured by the number of new people registering to the user
mailing list and the recent questions regarding applicability of OFBiz as a
solution for fleet management and logistic services.

Yes, getting a greater diversity (both in width and debt of skill level0
has to do with the actions of us all. Not just by PMC members or
committers. Not just by doing code changes. I am contributing my bit in
various areas.

Regards,



Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Fri, Oct 3, 2014 at 11:48 AM, Scott Gray scott.g...@hotwaxmedia.com
wrote:

 Do you have a link to the discussion they had Pierre?  It would be
 interesting to read more of the context.  Although even with one active
 contributor, it sounds like it is still doing better than our projectmgr
 component which has none.

 And yes it is quite true that projects have a decent amount of flexibility
 in what they can and cannot do.  I was simply saying that community
 diversity is a major factor in considering top-level project proposals and
 commonly (but apparently not always) in sub-projects as well, I think the
 reasons for this are self explanatory but yes exceptions are obviously also
 made sometimes.

 I just simply don't believe that our current approach could be so
 inhibiting that the component just sits there with no consistently active
 contributors.  Maybe the component needs more marketing?  Perhaps those
 with an interest in the component could consider writing some blog posts or
 mentioning it in relevant social media, forums, mailing lists etc., writing
 additional documentation may help too.  Perhaps you (Pierre) could consider
 contributing some of the customizations you mentioned having made.  My
 point is that there is much that could be done by anyone in the community
 who cares enough to do it.  Not every problem can be laid solely at the
 feet of the PMC (IMO very few actually can, but we obviously disagree on
 that).

 Regards
 Scott

 On 3/10/2014, at 9:45 pm, Pierre Smits pierre.sm...@gmail.com wrote:

  That does work for other top level projects under the ASF umbrella.
  Recently a discussion is started in the mailing list of Apache Directory
  server to adopt a new - external - component  as a sub project (the do
  everything in sub projects), that has only 1 committer and 1 contributor.
  There you also can't talk about having a great adoption within the
  community of that project, because it isn't there yet. But there are
  sentiments in favour of it, as it will expand the feature set of the
 works
  of the project and the visibility of the project itself.
 
  When you look at the CouchDb project, you'll see that they have dedicated
  mailing lists for various themes. You'll see that anything is possible
  under the ASF umbrella when you take a closer look.
 
  The Apache way is not to restricting people willing to do stuff, but to
  enable them. And often you need to promote to get the attention of
  contributors. Downplaying etc. does the opposite.
 
  Regards,
 
  Pierre Smits
 
  *ORRTIZ.COM http://www.orrtiz.com*
  Services  Solutions for Cloud-
  Based Manufacturing, Professional
  Services and Retail  Trade
  http://www.orrtiz.com
 
  On Fri, Oct 3, 2014 at 10:27 AM, Scott Gray scott.g...@hotwaxmedia.com
  wrote:
 
  Currently, the connection between individual modules and the people who
  care is a bit fuzzy and has resulted in decisions being taken by people
 who
  do not have a real interest in the particular modules that are being
  dropped. They have no way to connect with the interested parties or
 even to
  be sure about who they are.
  One of the values of sub-projects is that you capture groups that have
 a
  narrow interest in particular areas but are not able to commit to the
  entire project.
 
  We have mailing lists and jira to gauge interest in a specific
 component.
  Code contributions in particular are very useful in determining
 interest,
  unless you're suggesting that the component is perfect and no further
 work
  is required.  Everything in OFBiz has room for improvement and a lack of
  contributions is very much an indicator of a lack of interest in my
 opinion
  and experience with this project.
 
  It doesn't make any sense to create sub-projects in the hope that
 someone
  might show up and start community building.  The ASF doesn't work that
 way
  for top-level projects and

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-03 Thread Ron Wheeler


On 03/10/2014 4:27 AM, Scott Gray wrote:

Currently, the connection between individual modules and the people who care is 
a bit fuzzy and has resulted in decisions being taken by people who do not have 
a real interest in the particular modules that are being dropped. They have no 
way to connect with the interested parties or even to be sure about who they 
are.
One of the values of sub-projects is that you capture groups that have a narrow 
interest in particular areas but are not able to commit to the entire project.

We have mailing lists and jira to gauge interest in a specific component.  Code 
contributions in particular are very useful in determining interest, unless 
you're suggesting that the component is perfect and no further work is required.

It does not mean that end-users are not using the module.
It is also a real-world application that people are using as is right now.

   Everything in OFBiz has room for improvement and a lack of contributions is 
very much an indicator of a lack of interest in my opinion and experience with 
this project.


Of course, everything can be made better but that does not mean that you 
can throw out a perfectly good piece of code that is essential for some 
people just because no one is working on it.
This would result in 90% of Linux commands being dropped from the OS. 
Just because no one is working on grep does not mean that I can live 
without it.


Sub-projects would also provide a way for users to interact with a team 
whose only function is to maintain and enhance that particular module.





It doesn't make any sense to create sub-projects in the hope that someone might 
show up and start community building.  The ASF doesn't work that way for 
top-level projects and by the DB Project link you sent earlier implies they 
don't work that way for sub-projects either.  A community must exist around a 
given component before it can have any hope of standing on its own.


You are absolutely correct.
What is needed is a strategy and policy from the PMC to describe the 
conditions for establishing a sub-project.
Once that is done, it will be up to the community to step up with 
proposals for establishing a sub-project that meets the criteria laid out.
I am responding to the current need for a way for the PMC and 
contributors to attract people who have an interest in particular areas 
so that the group maintaining the core and the areas in which they are 
interested have an official team to work with to make sure that modules 
outside their interests are also maintained and are able to stay up to 
date with the Releases of the core functionality.
The user community needs to have a way to understand what modules are in 
or out of the system and a mechanism to support their favorites.


Another alternative is to fork the project into a separate project that 
only maintains the modules that are not released as part of the core 
OFBiz. This is less attractive for the users but may be the only 
alternative to maintaining a full range of end-user functionality.
It shifts more of the responsibility for integration to the end users 
but that is preferable to being unable to upgrade to the latest OFBiz 
due to features being lost between versions


I hope that the PMC members will do some investigation in this area and 
contact their Apache mentors and some of the projects that have 
extensive sub-project portfolios and see why they did this and what 
positive and negative results have been found over the years.




Regards
Scott

On 3/10/2014, at 7:50 pm, Ron Wheeler rwhee...@artifact-software.com wrote:


Are there a lot of outstanding JIRA issues that users want fixed?
It is not inconceivable that a module works as required.
I am not sure that measuring the usefulness of a module by the number of bugs 
or deficiencies found recently is accurate.

It seems to have been tested with the trunk as the core OFBiz has evolved.

It appears that it may need some testing with the ccore 13.07.01 Release before 
PROJECTMGR can be either said to work as is with 13.07.01 or released as a new 
version of PROJECTMGR that does work with 13.07.01.

If there was a sub-project with a following, there would be a group of people 
who want it to work and would be prepared to do what was required to keep the 
module functioning.
It would be quite clear to the people interested in PROJECTMGR that it was 
their responsibility to make sure that it was functional with 13.07.01.
Currently, the connection between individual modules and the people who care is 
a bit fuzzy and has resulted in decisions being taken by people who do not have 
a real interest in the particular modules that are being dropped. They have no 
way to connect with the interested parties or even to be sure about who they 
are.
One of the values of sub-projects is that you capture groups that have a narrow 
interest in particular areas but are not able to commit to the entire project.
The people working on the release of

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-03 Thread Ron Wheeler


It is a bit hard to market a module that is being dropped in 13.07.01.

On 03/10/2014 5:48 AM, Scott Gray wrote:

Do you have a link to the discussion they had Pierre?  It would be interesting 
to read more of the context.  Although even with one active contributor, it 
sounds like it is still doing better than our projectmgr component which has 
none.

And yes it is quite true that projects have a decent amount of flexibility in 
what they can and cannot do.  I was simply saying that community diversity is a 
major factor in considering top-level project proposals and commonly (but 
apparently not always) in sub-projects as well, I think the reasons for this 
are self explanatory but yes exceptions are obviously also made sometimes.

I just simply don't believe that our current approach could be so inhibiting 
that the component just sits there with no consistently active contributors.  
Maybe the component needs more marketing?  Perhaps those with an interest in 
the component could consider writing some blog posts or mentioning it in 
relevant social media, forums, mailing lists etc., writing additional 
documentation may help too.  Perhaps you (Pierre) could consider contributing 
some of the customizations you mentioned having made.  My point is that there 
is much that could be done by anyone in the community who cares enough to do 
it.  Not every problem can be laid solely at the feet of the PMC (IMO very few 
actually can, but we obviously disagree on that).

Regards
Scott

On 3/10/2014, at 9:45 pm, Pierre Smits pierre.sm...@gmail.com wrote:


That does work for other top level projects under the ASF umbrella.
Recently a discussion is started in the mailing list of Apache Directory
server to adopt a new - external - component  as a sub project (the do
everything in sub projects), that has only 1 committer and 1 contributor.
There you also can't talk about having a great adoption within the
community of that project, because it isn't there yet. But there are
sentiments in favour of it, as it will expand the feature set of the works
of the project and the visibility of the project itself.

When you look at the CouchDb project, you'll see that they have dedicated
mailing lists for various themes. You'll see that anything is possible
under the ASF umbrella when you take a closer look.

The Apache way is not to restricting people willing to do stuff, but to
enable them. And often you need to promote to get the attention of
contributors. Downplaying etc. does the opposite.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Fri, Oct 3, 2014 at 10:27 AM, Scott Gray scott.g...@hotwaxmedia.com
wrote:


Currently, the connection between individual modules and the people who

care is a bit fuzzy and has resulted in decisions being taken by people who
do not have a real interest in the particular modules that are being
dropped. They have no way to connect with the interested parties or even to
be sure about who they are.

One of the values of sub-projects is that you capture groups that have a

narrow interest in particular areas but are not able to commit to the
entire project.

We have mailing lists and jira to gauge interest in a specific component.
Code contributions in particular are very useful in determining interest,
unless you're suggesting that the component is perfect and no further work
is required.  Everything in OFBiz has room for improvement and a lack of
contributions is very much an indicator of a lack of interest in my opinion
and experience with this project.

It doesn't make any sense to create sub-projects in the hope that someone
might show up and start community building.  The ASF doesn't work that way
for top-level projects and by the DB Project link you sent earlier implies
they don't work that way for sub-projects either.  A community must exist
around a given component before it can have any hope of standing on its own.

Regards
Scott

On 3/10/2014, at 7:50 pm, Ron Wheeler rwhee...@artifact-software.com
wrote:


Are there a lot of outstanding JIRA issues that users want fixed?
It is not inconceivable that a module works as required.
I am not sure that measuring the usefulness of a module by the number of

bugs or deficiencies found recently is accurate.

It seems to have been tested with the trunk as the core OFBiz has

evolved.

It appears that it may need some testing with the ccore 13.07.01 Release

before PROJECTMGR can be either said to work as is with 13.07.01 or
released as a new version of PROJECTMGR that does work with 13.07.01.

If there was a sub-project with a following, there would be a group of

people who want it to work and would be prepared to do what was required to
keep the module functioning.

It would be quite clear to the people interested in PROJECTMGR that it

was their responsibility to make sure that it was functional with 13.07.01.

Re: [VOTE] PROJECTMGR in upcoming release

Grin,

That is like playing footbal (any kind) without the ball, and trying to
sell it as an attractive alternative.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Fri, Oct 3, 2014 at 5:07 PM, Ron Wheeler rwhee...@artifact-software.com
wrote:

 It is a bit hard to market a module that is being dropped in 13.07.01.


 On 03/10/2014 5:48 AM, Scott Gray wrote:

 Do you have a link to the discussion they had Pierre?  It would be
 interesting to read more of the context.  Although even with one active
 contributor, it sounds like it is still doing better than our projectmgr
 component which has none.

 And yes it is quite true that projects have a decent amount of
 flexibility in what they can and cannot do.  I was simply saying that
 community diversity is a major factor in considering top-level project
 proposals and commonly (but apparently not always) in sub-projects as well,
 I think the reasons for this are self explanatory but yes exceptions are
 obviously also made sometimes.

 I just simply don't believe that our current approach could be so
 inhibiting that the component just sits there with no consistently active
 contributors.  Maybe the component needs more marketing?  Perhaps those
 with an interest in the component could consider writing some blog posts or
 mentioning it in relevant social media, forums, mailing lists etc., writing
 additional documentation may help too.  Perhaps you (Pierre) could consider
 contributing some of the customizations you mentioned having made.  My
 point is that there is much that could be done by anyone in the community
 who cares enough to do it.  Not every problem can be laid solely at the
 feet of the PMC (IMO very few actually can, but we obviously disagree on
 that).

 Regards
 Scott

 On 3/10/2014, at 9:45 pm, Pierre Smits pierre.sm...@gmail.com wrote:

  That does work for other top level projects under the ASF umbrella.
 Recently a discussion is started in the mailing list of Apache Directory
 server to adopt a new - external - component  as a sub project (the do
 everything in sub projects), that has only 1 committer and 1 contributor.
 There you also can't talk about having a great adoption within the
 community of that project, because it isn't there yet. But there are
 sentiments in favour of it, as it will expand the feature set of the
 works
 of the project and the visibility of the project itself.

 When you look at the CouchDb project, you'll see that they have dedicated
 mailing lists for various themes. You'll see that anything is possible
 under the ASF umbrella when you take a closer look.

 The Apache way is not to restricting people willing to do stuff, but to
 enable them. And often you need to promote to get the attention of
 contributors. Downplaying etc. does the opposite.

 Regards,

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Fri, Oct 3, 2014 at 10:27 AM, Scott Gray scott.g...@hotwaxmedia.com
 wrote:

  Currently, the connection between individual modules and the people who

 care is a bit fuzzy and has resulted in decisions being taken by people
 who
 do not have a real interest in the particular modules that are being
 dropped. They have no way to connect with the interested parties or
 even to
 be sure about who they are.

 One of the values of sub-projects is that you capture groups that have
 a

 narrow interest in particular areas but are not able to commit to the
 entire project.

 We have mailing lists and jira to gauge interest in a specific
 component.
 Code contributions in particular are very useful in determining
 interest,
 unless you're suggesting that the component is perfect and no further
 work
 is required.  Everything in OFBiz has room for improvement and a lack of
 contributions is very much an indicator of a lack of interest in my
 opinion
 and experience with this project.

 It doesn't make any sense to create sub-projects in the hope that
 someone
 might show up and start community building.  The ASF doesn't work that
 way
 for top-level projects and by the DB Project link you sent earlier
 implies
 they don't work that way for sub-projects either.  A community must
 exist
 around a given component before it can have any hope of standing on its
 own.

 Regards
 Scott

 On 3/10/2014, at 7:50 pm, Ron Wheeler rwhee...@artifact-software.com
 wrote:

  Are there a lot of outstanding JIRA issues that users want fixed?
 It is not inconceivable that a module works as required.
 I am not sure that measuring the usefulness of a module by the number
 of

 bugs or deficiencies found recently is accurate.

 It seems to have been tested with the trunk as the core OFBiz has

 evolved.

 It appears that it may need some testing with the ccore 13.07.01
 Release

 before

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-02 Thread Ronan Keane

@Jacopo - I understand that no work effort entities have been moved out of
the release, my point was it seemed to me that originally in Ofbiz's
particular implementation/interpretation of the universal model, they may
have been moved out.

@Adrian - in Len Silverstone's model, within the supra-entity for managing
the work effort (track requirements to perform work, commitments to do work,
and the actual work that is being performed), there are sub entities for
program, project, phase, task, and activity. i.e. The work effort
may be subtyped according to its level of detail. c.f. diag.6.3a in his
book.

I do not see these entities in the entity definitions for work effort
module.

However, there are entities describing project, phase and task in the
project management module. Also entities for tracking efficiency of efforts
e.g. actual hours, actual rated hours etc. included in Silverstone's
conception of work effort.

To make the Work Effort Costing entities in the work effort module handle
certain job costing or project costing financial reporting requirements, it
seems to me that the project manager module is needed for break down of work
effort into the kind of detail required by particular sectors, and indeed
the tracking of efficiency of efforts etc.

Or there may be entities within Ofbiz's work effort costing section that may
be tweaked or adapted to handle such requirements that I do not adequately
understand yet - which I acknowledge as a relative newcomer.

--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Re-VOTE-PROJECTMGR-in-upcoming-release-tp4656231p4656383.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-02 Thread Adrian Crum

You are not understanding the diagram. You can see the WORK EFFORT
subtypes connected to WORK EFFORT TYPE. That is how the subtypes are
implemented - not as separate entities (or tables) but as a field in
WORK EFFORT (WORK EFFORT TYPE ID).

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/2/2014 9:54 AM, Ronan Keane wrote:

I do not see these entities in the entity definitions for work effort
module.

--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Re-VOTE-PROJECTMGR-in-upcoming-release-tp4656231p4656383.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-02 Thread Ronan Keane

Thank you for the clarification.



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Re-VOTE-PROJECTMGR-in-upcoming-release-tp4656231p4656398.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-02 Thread Jacques Le Roux

That's an interesting idea.

Now it also means more administration and we are already a bit sparse on the
volunteering front.

A simpler solution the OFBiz project used was to allow write access to only
parts of the repo.
This was before the Apache era. We gave up this way of doing because it was not
the Apache way.

I have not read it all yet but for instance I read in
https://community.apache.org/newcommitter.html
There may be extraordinary cases where we want limited work-related commit access.
This will be resolved during the vote discussion.

I don't know how technically this is possible in OFBiz trunk and branches,
apart maybe asking the infra team? Which would most probably faces a veto...

Jacques

Le 01/10/2014 16:46, Ron Wheeler a écrit :

The sub-project is a very useful Apache tool for helping projects grow.
http://db.apache.org/newproject.html is interesting reading.
http://ant.apache.org/antlibs/ very minimal description about Ant sub-projects
but we all use their work.
http://lucene.472066.n3.nabble.com/Close-of-Apache-Lucene-s-Open-Relevance-sub-project-td4141160.html a note about the official closure of a
sub-project - very clear about why and what closure means.
http://en.wikipedia.org/wiki/Apache_Ivy another popular sub-project. Description implies that it started in incubation and graduated to a top-level
package and then became a sub-project of Ant.

http://icodebythesea.blogspot.ca/2009/04/apache-servicemix-kernel-subproject.html
is an example of a sub-project moving between two top-level projects.

The sub-project structure allows for more specialization within the project resources so that people who are wizards with databases, kernels, etc
get to worry about data access, performance, scalability, reliability, security while others who have more domain interest get to worry about
features, usability, graphic design, workflow, reporting without getting in each other's hair.

It also ensures a clearer demarcation between framework, core ERP and modules.
I suspect that it would clean up project communication since people could
subscribe to the sub-project lists that pertained to their interests.

It might be easier for the existing community to accept new committers if the new people were part of a sub-project and were not committing to the
particular codebase (framework, core, etc.) that the current committers are working on.

It probably would help clarify the documentation since there would be a much clearer separation of framework from core from modules since each
sub-project would have its own section in the project documentation.
Each sub-project would have a much better defined target audience so writing docs would be a bit simpler and the language and terminology could be
more relevant to the target audience.

Ron

On 01/10/2014 10:17 AM, Pierre Smits wrote:

Ron,

In the past there was a WIKI page decribing who was interested and who was
willing to work on what. I don't know whether that page still exists.

In the past we also had a system of having committers dedicated and committed to a subset of the trunk. This should still be feasible. But for that
you need more committers. And to get more committers, this project needs to solicit and accept more.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com http://www.orrtiz.com/

On Wed, Oct 1, 2014 at 4:10 PM, Ron Wheeler rwhee...@artifact-software.com
mailto:rwhee...@artifact-software.com wrote:

A defined method of deciding what moves from the trunk to a
release would solve this.
Back to my previous comment about 1 person to test and 1 person to
fix bugs (could be the same person I suppose) would be a good
starting minimum.

Ron

On 01/10/2014 2:56 AM, Pierre Smits wrote:

The excuse of using PROJECTMgr in an older branch (12.x, the
latest stable
release) and testing it against trunk and therefor not
including it in a
release of a newer branch, is a lame one.

We are diligent about this, meaning that we do follow up
against any
potential new release branch in order to be able to migrate to
the newer
branch when there is something released.

Pierre Smits

*ORRTIZ.COM http://ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.com
mailto:jacopo.cappell...@hotwaxmedia.com wrote:

The fact that someone is using it in an older branch and
testing it in
trunk is not enough to guarantee it works well with 13.07;
the trunk and
13.07 are very different codebases.

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-02 Thread Jacopo Cappellato

In my opinion we should avoid reconsidering the idea of creating committers
with limited access; instead I would prefer to invite committers when we trust
them as individuals, when they have demonstrated the right attitude and skills
to work in our community etc... and demonstrate enough technical skills for the
work they have to do; even if it is limited to a subset of the OFBiz codebase
they will get full access to the repos but of course they will limit their
field of action to the area they know, without requiring us to enforce commit
rights limitations. As I said this can only work if we trust them 100% as
persons at first.

Jacopo

On Oct 2, 2014, at 2:30 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:

That's an interesting idea.

Now it also means more administration and we are already a bit sparse on the
volunteering front.

A simpler solution the OFBiz project used was to allow write access to only
parts of the repo.
This was before the Apache era. We gave up this way of doing because it was
not the Apache way.

I have not read it all yet but for instance I read in
https://community.apache.org/newcommitter.html
There may be extraordinary cases where we want limited work-related commit
access. This will be resolved during the vote discussion.

I don't know how technically this is possible in OFBiz trunk and branches,
apart maybe asking the infra team? Which would most probably faces a veto...

Jacques

Le 01/10/2014 16:46, Ron Wheeler a écrit :
The sub-project is a very useful Apache tool for helping projects grow.
http://db.apache.org/newproject.html is interesting reading.
http://ant.apache.org/antlibs/ very minimal description about Ant
sub-projects but we all use their work.
http://lucene.472066.n3.nabble.com/Close-of-Apache-Lucene-s-Open-Relevance-sub-project-td4141160.html
a note about the official closure of a sub-project - very clear about why
and what closure means.
http://en.wikipedia.org/wiki/Apache_Ivy another popular sub-project.
Description implies that it started in incubation and graduated to a
top-level package and then became a sub-project of Ant.
http://icodebythesea.blogspot.ca/2009/04/apache-servicemix-kernel-subproject.html
is an example of a sub-project moving between two top-level projects.

The sub-project structure allows for more specialization within the project
resources so that people who are wizards with databases, kernels, etc get to
worry about data access, performance, scalability, reliability, security
while others who have more domain interest get to worry about features,
usability, graphic design, workflow, reporting without getting in each
other's hair.

It also ensures a clearer demarcation between framework, core ERP and
modules.
I suspect that it would clean up project communication since people could
subscribe to the sub-project lists that pertained to their interests.

It might be easier for the existing community to accept new committers if
the new people were part of a sub-project and were not committing to the
particular codebase (framework, core, etc.) that the current committers are
working on.

It probably would help clarify the documentation since there would be a much
clearer separation of framework from core from modules since each
sub-project would have its own section in the project documentation.
Each sub-project would have a much better defined target audience so writing
docs would be a bit simpler and the language and terminology could be more
relevant to the target audience.

Ron

On 01/10/2014 10:17 AM, Pierre Smits wrote:
Ron,

In the past there was a WIKI page decribing who was interested and who was
willing to work on what. I don't know whether that page still exists.

In the past we also had a system of having committers dedicated and
committed to a subset of the trunk. This should still be feasible. But for
that you need more committers. And to get more committers, this project
needs to solicit and accept more.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com http://www.orrtiz.com/

On Wed, Oct 1, 2014 at 4:10 PM, Ron Wheeler rwhee...@artifact-software.com
mailto:rwhee...@artifact-software.com wrote:

Ron

On 01/10/2014 2:56 AM, Pierre Smits wrote:

The excuse of using PROJECTMgr in an older branch (12.x, the
latest stable
release) and testing it against trunk and therefor not
including it in a
release of a newer branch, is a lame one.

We are diligent about this,

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-02 Thread Ron Wheeler

Of course, I see a lot of benefit in the Apache approach of sub-projects
but perhaps the current group of committers should take some time to
consider this and talk to the Apache Mentors assigned to the project as
well as some of the project chairpersons from projects where
sub-projects are in use.

One of the advantages of being an Apache project is that there are many
things for which there is an Apache Way and there are people in the
broader Apache community that can provide information and guidance.

To Jacopo's point about trust.
I may trust someone to do one thing but not another.
I may trust someone with a critical task that I would not entrust to
another person who might be technically capable of doing it.

As a project manager, I may trust someone to work on a particular part
of an application but not on the data access.

For the project to grow, the people working on the framework are going
to have to get used to the idea that total strangers will be committing
code to the project.

The sub-project structure allows this to happen in a controlled way.

It also allows sub-projects to attract the right mix of people which
would be a totally different set of skills than the Framework project
would want.
Each sub-project will develop a team personality based on the
sub-project's mission and the type of people required to implement the
mission.
I would expect the framework sub-project to be hard core technical
people who know a lot about databases, security, entity modeling whereas
the e-Commerce team will have people who are very knowledgeable about
taxation, payment system integration, shopping cart design, user
experience, and end-user documentation.
The Project Management sub-project will attract people who know a lot
about billing for consulting companies, accounting firms and legal
offices as well project management, workflow, issue tracking, user
interfaces, web services, etc.
I would expect some overlap since many of the people here are very
senior and have skills in multiple areas but I suspect that most new
people will start in one sub-project and cut their teeth there before
joining another.

If it is done right it also makes everyone's job a lot easier and should
reduce the amount of ML traffic for each person.

Ron

On 02/10/2014 9:22 AM, Jacopo Cappellato wrote:

Jacopo

On Oct 2, 2014, at 2:30 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:

That's an interesting idea.

Now it also means more administration and we are already a bit sparse on the
volunteering front.

A simpler solution the OFBiz project used was to allow write access to only
parts of the repo.
This was before the Apache era. We gave up this way of doing because it was not
the Apache way.

I don't know how technically this is possible in OFBiz trunk and branches,
apart maybe asking the infra team? Which would most probably faces a veto...

Jacques

Le 01/10/2014 16:46, Ron Wheeler a écrit :

The sub-project is a very useful Apache tool for helping projects grow.
http://db.apache.org/newproject.html is interesting reading.
http://ant.apache.org/antlibs/ very minimal description about Ant sub-projects
but we all use their work.
http://lucene.472066.n3.nabble.com/Close-of-Apache-Lucene-s-Open-Relevance-sub-project-td4141160.html
a note about the official closure of a sub-project - very clear about why and
what closure means.
http://en.wikipedia.org/wiki/Apache_Ivy another popular sub-project.
Description implies that it started in incubation and graduated to a top-level
package and then became a sub-project of Ant.
http://icodebythesea.blogspot.ca/2009/04/apache-servicemix-kernel-subproject.html
is an example of a sub-project moving between two top-level projects.

The sub-project structure allows for more specialization within the project
resources so that people who are wizards with databases, kernels, etc get to
worry about data access, performance, scalability, reliability, security while
others who have more domain interest get to worry about features, usability,
graphic design, workflow,

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-02 Thread Scott Gray

Surely the first step in considering a specialized component for sub-project 
creation would be the level of activity surrounding the component?

Looking at the history of the projectmgr component I see 12 commits in the last 
TWO years 8 of which were global changes that coincidentally happened to touch 
on that component (translation work, global refactorings etc.).  This leaves 
only 4 commits specific to the component and even those are minor UI 
adjustments.

To be considered as a potential sub-project I would expect to see a hive of 
activity around that component with contributors specializing in solid 
contributions to further enhance it.  Build it and they will come is not a 
valid approach to sub-project creation.

If this component is so important to some of you, why are you not contributing 
to its enhancement?

Regards
Scott

On 3/10/2014, at 2:56 am, Ron Wheeler rwhee...@artifact-software.com wrote:

 Of course, I see a lot of benefit in the Apache approach of sub-projects but 
 perhaps the current group of committers should take some time to consider 
 this and talk to the Apache Mentors assigned to the project as well as some 
 of the project chairpersons from projects where sub-projects are in use.
 
 One of the advantages of being an Apache project is that there are many 
 things for which there is an Apache Way and there are people in the broader 
 Apache community that can provide information and guidance.
 
 To Jacopo's point about trust.
 I may trust someone to do one thing but not another.
 I may trust someone with a critical task that I would not entrust to another 
 person who might be technically capable of doing it.
 
 As a project manager, I may trust someone to work on a particular part of an 
 application but not on the data access.
 
 For the project to grow, the people working on the framework are going to 
 have to get used to the idea that total strangers will be committing code to 
 the project.
 The sub-project structure allows this to happen in a controlled way.
 
 It also allows sub-projects to attract the right mix of people which would 
 be a totally different set of skills than the Framework project would want.
 Each sub-project will develop a team personality based on the sub-project's 
 mission and the type of people required to implement the mission.
 I would expect the framework sub-project to be hard core technical people 
 who know a lot about databases, security, entity modeling whereas the 
 e-Commerce team will have people who are very knowledgeable about taxation, 
 payment system integration, shopping cart design, user experience, and 
 end-user documentation.
 The Project Management sub-project will attract people who know a lot about 
 billing for consulting companies, accounting firms and legal offices as well 
 project management, workflow, issue tracking, user interfaces, web services, 
 etc.
 I would expect some overlap since many of the people here are very senior and 
 have skills in multiple areas but I suspect that most new people will start 
 in one sub-project and cut their teeth there before joining another.
 
 If it is done right it also makes everyone's job a lot easier and should 
 reduce the amount of ML traffic for each person.
 
 
 Ron
 
 
 On 02/10/2014 9:22 AM, Jacopo Cappellato wrote:
 In my opinion we should avoid reconsidering the idea of creating committers 
 with limited access; instead I would prefer to invite committers when we 
 trust them as individuals, when they have demonstrated the right attitude 
 and skills to work in our community etc... and demonstrate enough technical 
 skills for the work they have to do; even if it is limited to a subset of 
 the OFBiz codebase they will get full access to the repos but of course they 
 will limit their field of action to the area they know, without requiring us 
 to enforce commit rights limitations. As I said this can only work if we 
 trust them 100% as persons at first.
 
 Jacopo
 
 On Oct 2, 2014, at 2:30 PM, Jacques Le Roux jacques.le.r...@les7arts.com 
 wrote:
 
 That's an interesting idea.
 
 Now it also means more administration and we are already a bit sparse on 
 the volunteering front.
 
 A simpler solution the OFBiz project used was to allow write access to only 
 parts of the repo.
 This was before the Apache era. We gave up this way of doing because it was 
 not the Apache way.
 
 I have not read it all yet but for instance I read in 
 https://community.apache.org/newcommitter.html
 There may be extraordinary cases where we want limited work-related 
 commit access. This will be resolved during the vote discussion. 
 
 I don't know how technically this is possible in OFBiz trunk and branches, 
 apart maybe asking the infra team? Which would most probably faces a veto...
 
 Jacques
 
 Le 01/10/2014 16:46, Ron Wheeler a écrit :
 The sub-project is a very useful Apache tool for helping projects grow.
 http://db.apache.org/newproject.html  is interesting reading.

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-02 Thread Jacques Le Roux


That's quite true Scott!

Jacques

Le 02/10/2014 21:02, Scott Gray a écrit :

Surely the first step in considering a specialized component for sub-project 
creation would be the level of activity surrounding the component?

Looking at the history of the projectmgr component I see 12 commits in the last 
TWO years 8 of which were global changes that coincidentally happened to touch 
on that component (translation work, global refactorings etc.).  This leaves 
only 4 commits specific to the component and even those are minor UI 
adjustments.

To be considered as a potential sub-project I would expect to see a hive of activity 
around that component with contributors specializing in solid contributions to further 
enhance it.  Build it and they will come is not a valid approach to 
sub-project creation.

If this component is so important to some of you, why are you not contributing 
to its enhancement?

Regards
Scott

On 3/10/2014, at 2:56 am, Ron Wheeler rwhee...@artifact-software.com wrote:


Of course, I see a lot of benefit in the Apache approach of sub-projects but 
perhaps the current group of committers should take some time to consider this 
and talk to the Apache Mentors assigned to the project as well as some of the 
project chairpersons from projects where sub-projects are in use.

One of the advantages of being an Apache project is that there are many things for which 
there is an Apache Way and there are people in the broader Apache community 
that can provide information and guidance.

To Jacopo's point about trust.
I may trust someone to do one thing but not another.
I may trust someone with a critical task that I would not entrust to another 
person who might be technically capable of doing it.

As a project manager, I may trust someone to work on a particular part of an 
application but not on the data access.

For the project to grow, the people working on the framework are going to have 
to get used to the idea that total strangers will be committing code to the 
project.
The sub-project structure allows this to happen in a controlled way.

It also allows sub-projects to attract the right mix of people which would be 
a totally different set of skills than the Framework project would want.
Each sub-project will develop a team personality based on the sub-project's 
mission and the type of people required to implement the mission.
I would expect the framework sub-project to be hard core technical people who 
know a lot about databases, security, entity modeling whereas the e-Commerce team will 
have people who are very knowledgeable about taxation, payment system integration, 
shopping cart design, user experience, and end-user documentation.
The Project Management sub-project will attract people who know a lot about 
billing for consulting companies, accounting firms and legal offices as well 
project management, workflow, issue tracking, user interfaces, web services, 
etc.
I would expect some overlap since many of the people here are very senior and have skills 
in multiple areas but I suspect that most new people will start in one sub-project and 
cut their teeth there before joining another.

If it is done right it also makes everyone's job a lot easier and should reduce 
the amount of ML traffic for each person.


Ron


On 02/10/2014 9:22 AM, Jacopo Cappellato wrote:

In my opinion we should avoid reconsidering the idea of creating committers 
with limited access; instead I would prefer to invite committers when we trust 
them as individuals, when they have demonstrated the right attitude and skills 
to work in our community etc... and demonstrate enough technical skills for the 
work they have to do; even if it is limited to a subset of the OFBiz codebase 
they will get full access to the repos but of course they will limit their 
field of action to the area they know, without requiring us to enforce commit 
rights limitations. As I said this can only work if we trust them 100% as 
persons at first.

Jacopo

On Oct 2, 2014, at 2:30 PM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:


That's an interesting idea.

Now it also means more administration and we are already a bit sparse on the 
volunteering front.

A simpler solution the OFBiz project used was to allow write access to only 
parts of the repo.
This was before the Apache era. We gave up this way of doing because it was not 
the Apache way.

I have not read it all yet but for instance I read in 
https://community.apache.org/newcommitter.html
There may be extraordinary cases where we want limited work-related commit access. 
This will be resolved during the vote discussion. 

I don't know how technically this is possible in OFBiz trunk and branches, 
apart maybe asking the infra team? Which would most probably faces a veto...

Jacques

Le 01/10/2014 16:46, Ron Wheeler a écrit :

The sub-project is a very useful Apache tool for helping projects grow.
http://db.apache.org/newproject.html  is interesting reading.

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-01 Thread Pierre Smits

That a component doesn't have any unit-tests is unfortunate, but can hardly
be regarded as a show stopper. A lot of code isn't covered with test cases.
Getting unit-tests is a catch-up game in this project. Even new additions
to a code get in to trunk and releases without those tests.
Even more so, the entire HUMANRES component doesn't have any unit tests and
is in the release.

As for code undergoing the 1-year long stabilization phase, when looking at
the HUMANRES component (see here:
http://svn.apache.org/viewvc/ofbiz/branches/release13.07/applications/humanres/)
you'll see that it got (approx) the same amount of love as the PROJECTMGR
component.



Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

 The fact that someone is using it in an older branch and testing it in
 trunk is not enough to guarantee it works well with 13.07; the trunk and
 13.07 are very different codebases.
 Additionally, the projectmgr component has 0 unit tests; I am not sure
 about about its stability, but for example comments in code like the
 following don't make me feel super confident:

 !-- temporary disabled because it caused a db lock with the
 checkProjectMembership in projectpermission services --

 One more point to note: since the component has not been in the 13.07
 branch, it didn't undergo the 1-year long stabilization phase where only
 bug-fixes are backported: for example, one month ago, with revision
 1618313, it was modified by a big commit to replace a series of Freemarker
 built-ins operation that we decided to not backport to 13.07 but only keep
 in the trunk.

 Jacopo

 On Sep 30, 2014, at 11:19 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

  So, as far as is known from Pierre's testing, there is no work required
 to stabilize and bug fix the module prior to including it in 13.07.01?
 
  Anyone else have any comments on the work required to include it in
 13.07.01?
 
  Ron
 
  On 30/09/2014 5:13 PM, Pierre Smits wrote:
  Ron, All,
 
  We use the latest released branch, meaning 12.x. We don't expose our
  customers to an unstable unreleased branch, that is still undergoing
  significant changes.
 
  But, we test our solutions against trunk. This enables us to identify
  issues and register them in JIRA. And supply patches when workload
 allows
  it.
 
  So yes, PROJECTMGR, SCRUM, etc work also in r13.x
 
  Regards,
 
  Pierre Smits
 
  *ORRTIZ.COM http://www.orrtiz.com*
  Services  Solutions for Cloud-
  Based Manufacturing, Professional
  Services and Retail  Trade
  http://www.orrtiz.com
 
  On Tue, Sep 30, 2014 at 10:22 PM, Ron Wheeler 
  rwhee...@artifact-software.com wrote:
 
  Are you using it with a 12.04 or 13.xx?
  What work is required to get it into 13.07?
 
  Ron
  On 30/09/2014 3:06 PM, Pierre Smits wrote:
 
  Yes, I also have a vested interest in keeping this (PROJECTMGR) in the
  releases. It is part of our ORRTIZ:COM solution portfolio for our
  customers
  and we use it internally. And I have contributed to the improvement
 of the
  component.
 
  We, at ORRTIZ:COM, even use an extension to the code base to ensure
 that
  it
  also works for fixed price and internal projects. This extension
 includes
  generating the gl transactions regarding the cost price of each hour
  registered regarding a project.
 
  We also use the LDAP component to connect to our directory server
 (Apache
  Directory Server).
 
  Regards,
 
  Pierre Smits
 
  *ORRTIZ.COM http://www.orrtiz.com*
  Services  Solutions for Cloud-
  Based Manufacturing, Professional
  Services and Retail  Trade
  http://www.orrtiz.com
 
  On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler
 rwheeler@artifact-software.
  com
 
  wrote:
  It would be for me since it is one of the components that I want to
 use.
 
  Perhaps the more knowledgeable people might want to share a bit more
 of
  the background of the feature.
  Is it in 12.xx.xx?
 
  Is it currently in the 13.07 branch and therefor currently part of
 the
  13.07 versions that people have put in production or is it just in
 the
  trunk that people are putting into production?
 
  What are the issues that need to be addressed before it is
 stabilized
  and
  bug fixed?
  Do any of these issues pose a significant risk to the stability of
 the
  rest of the functionality?
 
  Is anyone using it in production? What are their opinions of the
 state of
  the code and the degree of risk?
 
  Is anyone prepared to take on the task of getting it stabilized and
 bug
  fixed to a point where it can be safely included?
  What is the estimate of the minimum effort required?
 
  Ron
 
 
  On 30/09/2014 9:58 AM, Mike wrote:
 
   Why not deploy it as another hot-deploy component?   Is it
 considered a
  core ERP component?
 
  On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-01 Thread Pierre Smits

The excuse of using PROJECTMgr in an older branch (12.x, the latest stable
release) and testing it against trunk and therefor not including it in a
release of a newer branch, is a lame one.

We are diligent about this, meaning that we do follow up against any
potential new release branch in order to be able to migrate to the newer
branch when there is something released.

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

 The fact that someone is using it in an older branch and testing it in
 trunk is not enough to guarantee it works well with 13.07; the trunk and
 13.07 are very different codebases.
 Additionally, the projectmgr component has 0 unit tests; I am not sure
 about about its stability, but for example comments in code like the
 following don't make me feel super confident:

 !-- temporary disabled because it caused a db lock with the
 checkProjectMembership in projectpermission services --

 One more point to note: since the component has not been in the 13.07
 branch, it didn't undergo the 1-year long stabilization phase where only
 bug-fixes are backported: for example, one month ago, with revision
 1618313, it was modified by a big commit to replace a series of Freemarker
 built-ins operation that we decided to not backport to 13.07 but only keep
 in the trunk.

 Jacopo

 On Sep 30, 2014, at 11:19 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

  So, as far as is known from Pierre's testing, there is no work required
 to stabilize and bug fix the module prior to including it in 13.07.01?
 
  Anyone else have any comments on the work required to include it in
 13.07.01?
 
  Ron
 
  On 30/09/2014 5:13 PM, Pierre Smits wrote:
  Ron, All,
 
  We use the latest released branch, meaning 12.x. We don't expose our
  customers to an unstable unreleased branch, that is still undergoing
  significant changes.
 
  But, we test our solutions against trunk. This enables us to identify
  issues and register them in JIRA. And supply patches when workload
 allows
  it.
 
  So yes, PROJECTMGR, SCRUM, etc work also in r13.x
 
  Regards,
 
  Pierre Smits
 
  *ORRTIZ.COM http://www.orrtiz.com*
  Services  Solutions for Cloud-
  Based Manufacturing, Professional
  Services and Retail  Trade
  http://www.orrtiz.com
 
  On Tue, Sep 30, 2014 at 10:22 PM, Ron Wheeler 
  rwhee...@artifact-software.com wrote:
 
  Are you using it with a 12.04 or 13.xx?
  What work is required to get it into 13.07?
 
  Ron
  On 30/09/2014 3:06 PM, Pierre Smits wrote:
 
  Yes, I also have a vested interest in keeping this (PROJECTMGR) in the
  releases. It is part of our ORRTIZ:COM solution portfolio for our
  customers
  and we use it internally. And I have contributed to the improvement
 of the
  component.
 
  We, at ORRTIZ:COM, even use an extension to the code base to ensure
 that
  it
  also works for fixed price and internal projects. This extension
 includes
  generating the gl transactions regarding the cost price of each hour
  registered regarding a project.
 
  We also use the LDAP component to connect to our directory server
 (Apache
  Directory Server).
 
  Regards,
 
  Pierre Smits
 
  *ORRTIZ.COM http://www.orrtiz.com*
  Services  Solutions for Cloud-
  Based Manufacturing, Professional
  Services and Retail  Trade
  http://www.orrtiz.com
 
  On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler
 rwheeler@artifact-software.
  com
 
  wrote:
  It would be for me since it is one of the components that I want to
 use.
 
  Perhaps the more knowledgeable people might want to share a bit more
 of
  the background of the feature.
  Is it in 12.xx.xx?
 
  Is it currently in the 13.07 branch and therefor currently part of
 the
  13.07 versions that people have put in production or is it just in
 the
  trunk that people are putting into production?
 
  What are the issues that need to be addressed before it is
 stabilized
  and
  bug fixed?
  Do any of these issues pose a significant risk to the stability of
 the
  rest of the functionality?
 
  Is anyone using it in production? What are their opinions of the
 state of
  the code and the degree of risk?
 
  Is anyone prepared to take on the task of getting it stabilized and
 bug
  fixed to a point where it can be safely included?
  What is the estimate of the minimum effort required?
 
  Ron
 
 
  On 30/09/2014 9:58 AM, Mike wrote:
 
   Why not deploy it as another hot-deploy component?   Is it
 considered a
  core ERP component?
 
  On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits 
 pierre.sm...@gmail.com
  wrote:
 
Jacopo,
 
  Back then there were already strong objections to excluding
 components
  from
  the release. I recall that Hans also wanted to keep the SCRUM
 component
  in
  the release, as well as there were proponents for BIRT and other
  components.
 
  These

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-01 Thread Jacques Le Roux


Hi Pierre,

Sorry to say but it seems to me that you are beating a dead horse. By our policy, it's obvious you will not get the projectmgr component included in 
R13.07, despite all your arguments.


You should better lobby for its inclusion in R14.10 as Jacopo proposed.

For you customers you will have to handle the risk yourself for R13.07

Jacques

Le 01/10/2014 08:56, Pierre Smits a écrit :

The excuse of using PROJECTMgr in an older branch (12.x, the latest stable
release) and testing it against trunk and therefor not including it in a
release of a newer branch, is a lame one.

We are diligent about this, meaning that we do follow up against any
potential new release branch in order to be able to migrate to the newer
branch when there is something released.

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:


The fact that someone is using it in an older branch and testing it in
trunk is not enough to guarantee it works well with 13.07; the trunk and
13.07 are very different codebases.
Additionally, the projectmgr component has 0 unit tests; I am not sure
about about its stability, but for example comments in code like the
following don't make me feel super confident:

!-- temporary disabled because it caused a db lock with the
checkProjectMembership in projectpermission services --

One more point to note: since the component has not been in the 13.07
branch, it didn't undergo the 1-year long stabilization phase where only
bug-fixes are backported: for example, one month ago, with revision
1618313, it was modified by a big commit to replace a series of Freemarker
built-ins operation that we decided to not backport to 13.07 but only keep
in the trunk.

Jacopo

On Sep 30, 2014, at 11:19 PM, Ron Wheeler rwhee...@artifact-software.com
wrote:


So, as far as is known from Pierre's testing, there is no work required

to stabilize and bug fix the module prior to including it in 13.07.01?

Anyone else have any comments on the work required to include it in

13.07.01?

Ron

On 30/09/2014 5:13 PM, Pierre Smits wrote:

Ron, All,

We use the latest released branch, meaning 12.x. We don't expose our
customers to an unstable unreleased branch, that is still undergoing
significant changes.

But, we test our solutions against trunk. This enables us to identify
issues and register them in JIRA. And supply patches when workload

allows

it.

So yes, PROJECTMGR, SCRUM, etc work also in r13.x

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 10:22 PM, Ron Wheeler 
rwhee...@artifact-software.com wrote:


Are you using it with a 12.04 or 13.xx?
What work is required to get it into 13.07?

Ron
On 30/09/2014 3:06 PM, Pierre Smits wrote:


Yes, I also have a vested interest in keeping this (PROJECTMGR) in the
releases. It is part of our ORRTIZ:COM solution portfolio for our
customers
and we use it internally. And I have contributed to the improvement

of the

component.

We, at ORRTIZ:COM, even use an extension to the code base to ensure

that

it
also works for fixed price and internal projects. This extension

includes

generating the gl transactions regarding the cost price of each hour
registered regarding a project.

We also use the LDAP component to connect to our directory server

(Apache

Directory Server).

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler

rwheeler@artifact-software.

com


wrote:
It would be for me since it is one of the components that I want to

use.

Perhaps the more knowledgeable people might want to share a bit more

of

the background of the feature.
Is it in 12.xx.xx?

Is it currently in the 13.07 branch and therefor currently part of

the

13.07 versions that people have put in production or is it just in

the

trunk that people are putting into production?

What are the issues that need to be addressed before it is

stabilized

and
bug fixed?
Do any of these issues pose a significant risk to the stability of

the

rest of the functionality?

Is anyone using it in production? What are their opinions of the

state of

the code and the degree of risk?

Is anyone prepared to take on the task of getting it stabilized and

bug

fixed to a point where it can be safely included?
What is the estimate of the minimum effort required?

Ron


On 30/09/2014 9:58 AM, Mike wrote:

  Why not deploy it as another hot-deploy component?   Is it

considered a

core ERP component?

On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits 

pierre.sm...@gmail.com

wrote:

   Jacopo,


Back then there were

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-01 Thread Jacques Le Roux


Le 30/09/2014 17:20, Ted Byers a écrit :

It may be useful to look at how R handles these issues.  There is R-core,
and an R-core team, that is part of the main distribution (all packages
included in an installation of it), and then there is CRAN (similar in
concept to CPAN, for any Perl programmers out there - I hope it isn't
considered blasphemy to talk about Perl in this forum ;-)  ), to which all
members of the R community can contribute their packages; analogous to
components in the context of an application like OFBiz.  CRAN has a QA
protocol, which must be passed in order for an R package to be added to
CRAN; something that assures users that their system will not be trashed if
they instal a package available from CRAN.  And, sometimes, the R core team
decides that one of the packages on CRAN is so important and useful that
they decide to add it to core (this doesn't happen often, but it does
happen).  So then, in the context of OFBiz, the first question becomes, can
the hot-deploy support be used in a manner similar to a snadbox that
protext the rest of the system from badly behaved code (NB: I am not
implying anything about the code in the component in question now, but
rather thinking in general terms for any new component anyone may want to
contribute)?  And then, the question becomes, what protocol can be used for
promoting components from the 'sandbox' to incorporation into the 'core
release'; whatever you want to call it?


Hi Ted, it seems  you were more thinking aloud :) but let me try to answer you

In ASF project lazy consensus is used. In other words, it's discussed by the project community and if really people can't get to an agreement a vote 
is open. Then only PMC members have binding votes http://www.apache.org/foundation/voting.html.


The issue about projectmanager Pierre raised has already been discussed and we decided to keep only ecommerce in specialpurpose. Before some 
components (projectmanager for instance) had been moved from applicationd to specialpurpose. It's maybe unfortunate. But, as Jacopo suggested, we (so 
far, Jacopo and I at least) are open to discuss this again and indeed projectmanager and few other components could get back to specialpurpose IMO. 
Adding Junit tests then would be a good thing.


Note that, though Erwan (a PMC member, no longer an active committer) tried to install the whole flow, we don't have a mean to test the UI in the 
project. I know though this is done by some other service providers.


I hope I answered you

Jacques



Cheers

Ted

Re: [VOTE] PROJECTMGR in upcoming release

temorarily disabled... Certainly seems like a note that should cause 
some careful analysis.

Did the author of the comment create a JIRA issue to address this problem?

Is there any guidance about unit tests?
Can a JIRA issue (or set of issues) be created describing the unit tests 
that must be done to get this into a stable release?


On a more general note:
It looks like there are a number of other modules in the same situation.
Is there currently any way to track who is interested in working on 
these modules (code, docs, testing, etc.) so that modules do not 
disappear between releases.


It is unsettling for a user community to have functionality disappear 
during an upgrade.

It would certainly causes a loss of faith in the product if:
a) you can not upgrade because modules you use in the current release 
are missing and

 b) at the same time, you see support being withdrawn from older versions.

This raises a topic that came a few weeks ago while we were cleaning up 
the product description.
There needs to be a clear statement of what OFBiz provides and what are 
modules that are not considered part of OFBiz but are extensions that 
someone other than the core OFBiz team provides as part of every release.
It appears that PROJECTMGR falls into that second category and is not 
part of the official OFBiz product.


This is not necessarily a bad thing but it needs to be stated very clearly.
As I understand The Apache Way, this would result in a set of 
sub-projects under OFBiz with sets of identified contributors who work 
on these sub-projects.

This way, there are no orphans that no one supports.
Unsupported projects would become dead projects whereby the end-users 
could use the code base with the understanding that they are solely 
responsible for maintaining changes to the code on their own SCM until 
such time as they are able to commit the code back with the permission 
of the PMC.
There would be a clear understanding on the part of the user community 
that they are taking a risk by using the supported extensions since they 
may get caught in a dead end if the project dies or at a minimum a delay 
in being able to upgrade. They would at least know where they stand a 
bit better and the team working on the core product would have a clearer 
mandate.


It should also force the main group and the maintainers of each 
sub-project to identify the interfacing points between each system so 
that the impact of changes to the OFBiz core would be understood a bit 
better.


It would also provide a local incubation process where extensions could 
be proposed as sub-projects and the more successful (active team, many 
users) sub-projects could be elevated to the core.


Ron


On 01/10/2014 1:45 AM, Jacopo Cappellato wrote:

The fact that someone is using it in an older branch and testing it in trunk is 
not enough to guarantee it works well with 13.07; the trunk and 13.07 are very 
different codebases.
Additionally, the projectmgr component has 0 unit tests; I am not sure about 
about its stability, but for example comments in code like the following don't make me 
feel super confident:

!-- temporary disabled because it caused a db lock with the 
checkProjectMembership in projectpermission services --

One more point to note: since the component has not been in the 13.07 branch, 
it didn't undergo the 1-year long stabilization phase where only bug-fixes are 
backported: for example, one month ago, with revision 1618313, it was modified 
by a big commit to replace a series of Freemarker built-ins operation that we 
decided to not backport to 13.07 but only keep in the trunk.

Jacopo

On Sep 30, 2014, at 11:19 PM, Ron Wheeler rwhee...@artifact-software.com 
wrote:


So, as far as is known from Pierre's testing, there is no work required to 
stabilize and bug fix the module prior to including it in 13.07.01?

Anyone else have any comments on the work required to include it in 13.07.01?

Ron

On 30/09/2014 5:13 PM, Pierre Smits wrote:

Ron, All,

We use the latest released branch, meaning 12.x. We don't expose our
customers to an unstable unreleased branch, that is still undergoing
significant changes.

But, we test our solutions against trunk. This enables us to identify
issues and register them in JIRA. And supply patches when workload allows
it.

So yes, PROJECTMGR, SCRUM, etc work also in r13.x

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 10:22 PM, Ron Wheeler 
rwhee...@artifact-software.com wrote:


Are you using it with a 12.04 or 13.xx?
What work is required to get it into 13.07?

Ron
On 30/09/2014 3:06 PM, Pierre Smits wrote:


Yes, I also have a vested interest in keeping this (PROJECTMGR) in the
releases. It is part of our ORRTIZ:COM solution portfolio for our
customers
and we use it internally. And I have contributed to the improvement of the

Re: [VOTE] PROJECTMGR in upcoming release


What unit tests should it have?
It is hard to create a general rule about unit tests specially for 
software that is predominately UI.

Does anyone have any concrete suggestions on PROJECTMGR ?

Clearly, getting something into Release Candidates early gives the user 
community a chance to test the UI parts and identify deficiencies.


There should be some objective list of criteria to decide when an 
extension is ready for inclusion in a Release Candidate.
Could be as simple as having one person agree to test it and at least 
one person agree to fix any bugs found.


Ron

On 01/10/2014 2:43 AM, Pierre Smits wrote:

That a component doesn't have any unit-tests is unfortunate, but can hardly
be regarded as a show stopper. A lot of code isn't covered with test cases.
Getting unit-tests is a catch-up game in this project. Even new additions
to a code get in to trunk and releases without those tests.
Even more so, the entire HUMANRES component doesn't have any unit tests and
is in the release.

As for code undergoing the 1-year long stabilization phase, when looking at
the HUMANRES component (see here:
http://svn.apache.org/viewvc/ofbiz/branches/release13.07/applications/humanres/)
you'll see that it got (approx) the same amount of love as the PROJECTMGR
component.



Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:


The fact that someone is using it in an older branch and testing it in
trunk is not enough to guarantee it works well with 13.07; the trunk and
13.07 are very different codebases.
Additionally, the projectmgr component has 0 unit tests; I am not sure
about about its stability, but for example comments in code like the
following don't make me feel super confident:

!-- temporary disabled because it caused a db lock with the
checkProjectMembership in projectpermission services --

One more point to note: since the component has not been in the 13.07
branch, it didn't undergo the 1-year long stabilization phase where only
bug-fixes are backported: for example, one month ago, with revision
1618313, it was modified by a big commit to replace a series of Freemarker
built-ins operation that we decided to not backport to 13.07 but only keep
in the trunk.

Jacopo

On Sep 30, 2014, at 11:19 PM, Ron Wheeler rwhee...@artifact-software.com
wrote:


So, as far as is known from Pierre's testing, there is no work required

to stabilize and bug fix the module prior to including it in 13.07.01?

Anyone else have any comments on the work required to include it in

13.07.01?

Ron

On 30/09/2014 5:13 PM, Pierre Smits wrote:

Ron, All,

We use the latest released branch, meaning 12.x. We don't expose our
customers to an unstable unreleased branch, that is still undergoing
significant changes.

But, we test our solutions against trunk. This enables us to identify
issues and register them in JIRA. And supply patches when workload

allows

it.

So yes, PROJECTMGR, SCRUM, etc work also in r13.x

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 10:22 PM, Ron Wheeler 
rwhee...@artifact-software.com wrote:


Are you using it with a 12.04 or 13.xx?
What work is required to get it into 13.07?

Ron
On 30/09/2014 3:06 PM, Pierre Smits wrote:


Yes, I also have a vested interest in keeping this (PROJECTMGR) in the
releases. It is part of our ORRTIZ:COM solution portfolio for our
customers
and we use it internally. And I have contributed to the improvement

of the

component.

We, at ORRTIZ:COM, even use an extension to the code base to ensure

that

it
also works for fixed price and internal projects. This extension

includes

generating the gl transactions regarding the cost price of each hour
registered regarding a project.

We also use the LDAP component to connect to our directory server

(Apache

Directory Server).

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler

rwheeler@artifact-software.

com


wrote:
It would be for me since it is one of the components that I want to

use.

Perhaps the more knowledgeable people might want to share a bit more

of

the background of the feature.
Is it in 12.xx.xx?

Is it currently in the 13.07 branch and therefor currently part of

the

13.07 versions that people have put in production or is it just in

the

trunk that people are putting into production?

What are the issues that need to be addressed before it is

stabilized

and
bug fixed?
Do any of these issues pose a significant risk to the stability of

the

rest of the functionality?

Is anyone using it in

Re: [VOTE] PROJECTMGR in upcoming release

A defined method of deciding what moves from the trunk to a release 
would solve this.
Back to my previous comment about 1 person to test and 1 person to fix 
bugs (could be the same person I suppose) would be a good starting minimum.


Ron

On 01/10/2014 2:56 AM, Pierre Smits wrote:

The excuse of using PROJECTMgr in an older branch (12.x, the latest stable
release) and testing it against trunk and therefor not including it in a
release of a newer branch, is a lame one.

We are diligent about this, meaning that we do follow up against any
potential new release branch in order to be able to migrate to the newer
branch when there is something released.

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:


The fact that someone is using it in an older branch and testing it in
trunk is not enough to guarantee it works well with 13.07; the trunk and
13.07 are very different codebases.
Additionally, the projectmgr component has 0 unit tests; I am not sure
about about its stability, but for example comments in code like the
following don't make me feel super confident:

!-- temporary disabled because it caused a db lock with the
checkProjectMembership in projectpermission services --

One more point to note: since the component has not been in the 13.07
branch, it didn't undergo the 1-year long stabilization phase where only
bug-fixes are backported: for example, one month ago, with revision
1618313, it was modified by a big commit to replace a series of Freemarker
built-ins operation that we decided to not backport to 13.07 but only keep
in the trunk.

Jacopo

On Sep 30, 2014, at 11:19 PM, Ron Wheeler rwhee...@artifact-software.com
wrote:


So, as far as is known from Pierre's testing, there is no work required

to stabilize and bug fix the module prior to including it in 13.07.01?

Anyone else have any comments on the work required to include it in

13.07.01?

Ron

On 30/09/2014 5:13 PM, Pierre Smits wrote:

Ron, All,

We use the latest released branch, meaning 12.x. We don't expose our
customers to an unstable unreleased branch, that is still undergoing
significant changes.

But, we test our solutions against trunk. This enables us to identify
issues and register them in JIRA. And supply patches when workload

allows

it.

So yes, PROJECTMGR, SCRUM, etc work also in r13.x

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 10:22 PM, Ron Wheeler 
rwhee...@artifact-software.com wrote:


Are you using it with a 12.04 or 13.xx?
What work is required to get it into 13.07?

Ron
On 30/09/2014 3:06 PM, Pierre Smits wrote:


Yes, I also have a vested interest in keeping this (PROJECTMGR) in the
releases. It is part of our ORRTIZ:COM solution portfolio for our
customers
and we use it internally. And I have contributed to the improvement

of the

component.

We, at ORRTIZ:COM, even use an extension to the code base to ensure

that

it
also works for fixed price and internal projects. This extension

includes

generating the gl transactions regarding the cost price of each hour
registered regarding a project.

We also use the LDAP component to connect to our directory server

(Apache

Directory Server).

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler

rwheeler@artifact-software.

com


wrote:
It would be for me since it is one of the components that I want to

use.

Perhaps the more knowledgeable people might want to share a bit more

of

the background of the feature.
Is it in 12.xx.xx?

Is it currently in the 13.07 branch and therefor currently part of

the

13.07 versions that people have put in production or is it just in

the

trunk that people are putting into production?

What are the issues that need to be addressed before it is

stabilized

and
bug fixed?
Do any of these issues pose a significant risk to the stability of

the

rest of the functionality?

Is anyone using it in production? What are their opinions of the

state of

the code and the degree of risk?

Is anyone prepared to take on the task of getting it stabilized and

bug

fixed to a point where it can be safely included?
What is the estimate of the minimum effort required?

Ron


On 30/09/2014 9:58 AM, Mike wrote:

  Why not deploy it as another hot-deploy component?   Is it

considered a

core ERP component?

On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits 

pierre.sm...@gmail.com

wrote:

   Jacopo,


Back then there were already strong objections to excluding

components

from
the release. I recall that Hans also wanted to keep the

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-01 Thread Pierre Smits

Ron,

In the past there was a WIKI page decribing who was interested and who was
willing to work on what. I don't know whether that page still exists.

In the past we also had a system of having committers dedicated and
committed to a subset of the trunk. This should still be feasible. But for
that you need more committers. And to get more committers, this project
needs to solicit and accept more.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 4:10 PM, Ron Wheeler rwhee...@artifact-software.com
wrote:

 A defined method of deciding what moves from the trunk to a release would
 solve this.
 Back to my previous comment about 1 person to test and 1 person to fix
 bugs (could be the same person I suppose) would be a good starting minimum.

 Ron

 On 01/10/2014 2:56 AM, Pierre Smits wrote:

 The excuse of using PROJECTMgr in an older branch (12.x, the latest stable
 release) and testing it against trunk and therefor not including it in a
 release of a newer branch, is a lame one.

 We are diligent about this, meaning that we do follow up against any
 potential new release branch in order to be able to migrate to the newer
 branch when there is something released.

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:

  The fact that someone is using it in an older branch and testing it in
 trunk is not enough to guarantee it works well with 13.07; the trunk and
 13.07 are very different codebases.
 Additionally, the projectmgr component has 0 unit tests; I am not sure
 about about its stability, but for example comments in code like the
 following don't make me feel super confident:

 !-- temporary disabled because it caused a db lock with the
 checkProjectMembership in projectpermission services --

 One more point to note: since the component has not been in the 13.07
 branch, it didn't undergo the 1-year long stabilization phase where only
 bug-fixes are backported: for example, one month ago, with revision
 1618313, it was modified by a big commit to replace a series of
 Freemarker
 built-ins operation that we decided to not backport to 13.07 but only
 keep
 in the trunk.

 Jacopo

 On Sep 30, 2014, at 11:19 PM, Ron Wheeler rwheeler@artifact-software.
 com
 wrote:

  So, as far as is known from Pierre's testing, there is no work required

 to stabilize and bug fix the module prior to including it in 13.07.01?

 Anyone else have any comments on the work required to include it in

 13.07.01?

 Ron

 On 30/09/2014 5:13 PM, Pierre Smits wrote:

 Ron, All,

 We use the latest released branch, meaning 12.x. We don't expose our
 customers to an unstable unreleased branch, that is still undergoing
 significant changes.

 But, we test our solutions against trunk. This enables us to identify
 issues and register them in JIRA. And supply patches when workload

 allows

 it.

 So yes, PROJECTMGR, SCRUM, etc work also in r13.x

 Regards,

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Tue, Sep 30, 2014 at 10:22 PM, Ron Wheeler 
 rwhee...@artifact-software.com wrote:

  Are you using it with a 12.04 or 13.xx?
 What work is required to get it into 13.07?

 Ron
 On 30/09/2014 3:06 PM, Pierre Smits wrote:

  Yes, I also have a vested interest in keeping this (PROJECTMGR) in
 the
 releases. It is part of our ORRTIZ:COM solution portfolio for our
 customers
 and we use it internally. And I have contributed to the improvement

 of the

 component.

 We, at ORRTIZ:COM, even use an extension to the code base to ensure

 that

 it
 also works for fixed price and internal projects. This extension

 includes

 generating the gl transactions regarding the cost price of each hour
 registered regarding a project.

 We also use the LDAP component to connect to our directory server

 (Apache

 Directory Server).

 Regards,

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler

 rwheeler@artifact-software.

 com

  wrote:
 It would be for me since it is one of the components that I want to

 use.

 Perhaps the more knowledgeable people might want to share a bit more

 of

 the background of the feature.
 Is it in 12.xx.xx?

 Is it currently in the 13.07 branch and therefor currently part of

 the

 13.07 versions that people have put in production or is it just in

 the

 trunk that people are putting into production?

 What are the issues that need to be addressed before it is

 stabilized

 and

Re: [VOTE] PROJECTMGR in upcoming release

The sub-project is a very useful Apache tool for helping projects grow.
http://db.apache.org/newproject.html is interesting reading.
http://ant.apache.org/antlibs/ very minimal description about Ant
sub-projects but we all use their work.
http://lucene.472066.n3.nabble.com/Close-of-Apache-Lucene-s-Open-Relevance-sub-project-td4141160.html
a note about the official closure of a sub-project - very clear about
why and what closure means.
http://en.wikipedia.org/wiki/Apache_Ivy another popular sub-project.
Description implies that it started in incubation and graduated to a
top-level package and then became a sub-project of Ant.
http://icodebythesea.blogspot.ca/2009/04/apache-servicemix-kernel-subproject.html
is an example of a sub-project moving between two top-level projects.

The sub-project structure allows for more specialization within the
project resources so that people who are wizards with databases,
kernels, etc get to worry about data access, performance, scalability,
reliability, security while others who have more domain interest get to
worry about features, usability, graphic design, workflow, reporting
without getting in each other's hair.

It also ensures a clearer demarcation between framework, core ERP and
modules.
I suspect that it would clean up project communication since people
could subscribe to the sub-project lists that pertained to their interests.

It might be easier for the existing community to accept new committers
if the new people were part of a sub-project and were not committing to
the particular codebase (framework, core, etc.) that the current
committers are working on.

It probably would help clarify the documentation since there would be a
much clearer separation of framework from core from modules since each
sub-project would have its own section in the project documentation.
Each sub-project would have a much better defined target audience so
writing docs would be a bit simpler and the language and terminology
could be more relevant to the target audience.

Ron

On 01/10/2014 10:17 AM, Pierre Smits wrote:

Ron,

In the past there was a WIKI page decribing who was interested and who
was willing to work on what. I don't know whether that page still exists.

In the past we also had a system of having committers dedicated and
committed to a subset of the trunk. This should still be feasible. But
for that you need more committers. And to get more committers, this
project needs to solicit and accept more.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com http://www.orrtiz.com/

On Wed, Oct 1, 2014 at 4:10 PM, Ron Wheeler
rwhee...@artifact-software.com
mailto:rwhee...@artifact-software.com wrote:

Ron

On 01/10/2014 2:56 AM, Pierre Smits wrote:

The excuse of using PROJECTMgr in an older branch (12.x, the
latest stable
release) and testing it against trunk and therefor not
including it in a
release of a newer branch, is a lame one.

We are diligent about this, meaning that we do follow up
against any
potential new release branch in order to be able to migrate to
the newer
branch when there is something released.

Pierre Smits

*ORRTIZ.COM http://ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.com
mailto:jacopo.cappell...@hotwaxmedia.com wrote:

The fact that someone is using it in an older branch and
testing it in
trunk is not enough to guarantee it works well with 13.07;
the trunk and
13.07 are very different codebases.
Additionally, the projectmgr component has 0 unit tests;
I am not sure
about about its stability, but for example comments in
code like the
following don't make me feel super confident:

!-- temporary disabled because it caused a db lock with the
checkProjectMembership in projectpermission services --

One more point to note: since the component has not been
in the 13.07
branch, it didn't undergo the 1-year long stabilization
phase where only
bug-fixes are backported: for example, one month ago, with
revision
1618313, it was modified by a big commit to replace a
series of

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-01 Thread Todd Thorner

This sounds good. But then, what do I know?

I am still willing to pitch in on documentation, once I wrap my head
around the project (or a potential sub-project). For now it's a matter
of free time and all that ...

On 14-10-01 07:46 AM, Ron Wheeler wrote:
The sub-project is a very useful Apache tool for helping projects grow.
http://db.apache.org/newproject.html is interesting reading.
http://ant.apache.org/antlibs/ very minimal description about Ant
sub-projects but we all use their work.
http://lucene.472066.n3.nabble.com/Close-of-Apache-Lucene-s-Open-Relevance-sub-project-td4141160.html
a note about the official closure of a sub-project - very clear about
why and what closure means.
http://en.wikipedia.org/wiki/Apache_Ivy another popular sub-project.
Description implies that it started in incubation and graduated to a
top-level package and then became a sub-project of Ant.
http://icodebythesea.blogspot.ca/2009/04/apache-servicemix-kernel-subproject.html
is an example of a sub-project moving between two top-level projects.

The sub-project structure allows for more specialization within the
project resources so that people who are wizards with databases,
kernels, etc get to worry about data access, performance, scalability,
reliability, security while others who have more domain interest get to
worry about features, usability, graphic design, workflow, reporting
without getting in each other's hair.

It also ensures a clearer demarcation between framework, core ERP and
modules.
I suspect that it would clean up project communication since people
could subscribe to the sub-project lists that pertained to their interests.

It might be easier for the existing community to accept new committers
if the new people were part of a sub-project and were not committing to
the particular codebase (framework, core, etc.) that the current
committers are working on.

It probably would help clarify the documentation since there would be a
much clearer separation of framework from core from modules since each
sub-project would have its own section in the project documentation.
Each sub-project would have a much better defined target audience so
writing docs would be a bit simpler and the language and terminology
could be more relevant to the target audience.

Ron

On 01/10/2014 10:17 AM, Pierre Smits wrote:
Ron,

In the past there was a WIKI page decribing who was interested and who
was willing to work on what. I don't know whether that page still exists.

In the past we also had a system of having committers dedicated and
committed to a subset of the trunk. This should still be feasible. But
for that you need more committers. And to get more committers, this
project needs to solicit and accept more.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com http://www.orrtiz.com/

On Wed, Oct 1, 2014 at 4:10 PM, Ron Wheeler
rwhee...@artifact-software.com
mailto:rwhee...@artifact-software.com wrote:

Ron

On 01/10/2014 2:56 AM, Pierre Smits wrote:

The excuse of using PROJECTMgr in an older branch (12.x, the
latest stable
release) and testing it against trunk and therefor not
including it in a
release of a newer branch, is a lame one.

We are diligent about this, meaning that we do follow up
against any
potential new release branch in order to be able to migrate to
the newer
branch when there is something released.

Pierre Smits

*ORRTIZ.COM http://ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.com
mailto:jacopo.cappell...@hotwaxmedia.com wrote:

!-- temporary disabled because it caused a db lock with the
checkProjectMembership in projectpermission services --

One more point to note: since the component has

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-01 Thread Ronan Keane

With a view to 14.10 just a brief (rookie) comment on this - it strikes that
there were entities within Len Silverstone's modelling of work effort that
were shifted out to the project management module (also asset maintenance
module). Without them, the ability to model work effort adequately will be
reduced, at least in terms of the concept of A library of universal data
models for ALL enterprises.  i.e. There will be a reduction in capability
to model the requirements of certain sectors.


Mike Z wrote
 ...  Is it considered a core ERP component?





--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Re-VOTE-PROJECTMGR-in-upcoming-release-tp4656231p4656351.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-01 Thread Jacopo Cappellato

Hi Ronan,

no work effort entities has been moved out of the release: they are all in 
the workeffort component. The two components (asset maintenance and projectmgr) 
are just two specialized applications built on top of the universal data model 
delivered in OFBiz.

Jacopo

On Oct 1, 2014, at 6:47 PM, Ronan Keane ro...@cloudbroker.ie wrote:

 With a view to 14.10 just a brief (rookie) comment on this - it strikes that
 there were entities within Len Silverstone's modelling of work effort that
 were shifted out to the project management module (also asset maintenance
 module). Without them, the ability to model work effort adequately will be
 reduced, at least in terms of the concept of A library of universal data
 models for ALL enterprises.  i.e. There will be a reduction in capability
 to model the requirements of certain sectors.
 
 
 Mike Z wrote
 ...  Is it considered a core ERP component?
 
 
 
 
 
 --
 View this message in context: 
 http://ofbiz.135035.n4.nabble.com/Re-VOTE-PROJECTMGR-in-upcoming-release-tp4656231p4656351.html
 Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-01 Thread Adrian Crum

As far as I can tell, those components implement view entities only - so 
the data model resides within the core applications. Could you provide 
an example of where entities were shifted out to special purpose components?


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/1/2014 5:47 PM, Ronan Keane wrote:

With a view to 14.10 just a brief (rookie) comment on this - it strikes that
there were entities within Len Silverstone's modelling of work effort that
were shifted out to the project management module (also asset maintenance
module). Without them, the ability to model work effort adequately will be
reduced, at least in terms of the concept of A library of universal data
models for ALL enterprises.  i.e. There will be a reduction in capability
to model the requirements of certain sectors.


Mike Z wrote

...  Is it considered a core ERP component?






--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Re-VOTE-PROJECTMGR-in-upcoming-release-tp4656231p4656351.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: [VOTE] PROJECTMGR in upcoming release

2014-10-01 Thread Jacques Le Roux

I guess you think about
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

Jacques

Le 01/10/2014 16:17, Pierre Smits a écrit :

Ron,

In the past there was a WIKI page decribing who was interested and who was
willing to work on what. I don't know whether that page still exists.

In the past we also had a system of having committers dedicated and
committed to a subset of the trunk. This should still be feasible. But for
that you need more committers. And to get more committers, this project
needs to solicit and accept more.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 4:10 PM, Ron Wheeler rwhee...@artifact-software.com
wrote:

A defined method of deciding what moves from the trunk to a release would
solve this.
Back to my previous comment about 1 person to test and 1 person to fix
bugs (could be the same person I suppose) would be a good starting minimum.

Ron

On 01/10/2014 2:56 AM, Pierre Smits wrote:

The excuse of using PROJECTMgr in an older branch (12.x, the latest stable
release) and testing it against trunk and therefor not including it in a
release of a newer branch, is a lame one.

We are diligent about this, meaning that we do follow up against any
potential new release branch in order to be able to migrate to the newer
branch when there is something released.

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com

On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.com wrote:

The fact that someone is using it in an older branch and testing it in

trunk is not enough to guarantee it works well with 13.07; the trunk and
13.07 are very different codebases.
Additionally, the projectmgr component has 0 unit tests; I am not sure
about about its stability, but for example comments in code like the
following don't make me feel super confident:

!-- temporary disabled because it caused a db lock with the
checkProjectMembership in projectpermission services --

One more point to note: since the component has not been in the 13.07
branch, it didn't undergo the 1-year long stabilization phase where only
bug-fixes are backported: for example, one month ago, with revision
1618313, it was modified by a big commit to replace a series of
Freemarker
built-ins operation that we decided to not backport to 13.07 but only
keep
in the trunk.

Jacopo

On Sep 30, 2014, at 11:19 PM, Ron Wheeler rwheeler@artifact-software.
com
wrote:

So, as far as is known from Pierre's testing, there is no work required
to stabilize and bug fix the module prior to including it in 13.07.01?

Anyone else have any comments on the work required to include it in

13.07.01?

Ron

On 30/09/2014 5:13 PM, Pierre Smits wrote:

Ron, All,

We use the latest released branch, meaning 12.x. We don't expose our
customers to an unstable unreleased branch, that is still undergoing
significant changes.

But, we test our solutions against trunk. This enables us to identify
issues and register them in JIRA. And supply patches when workload

allows
it.

So yes, PROJECTMGR, SCRUM, etc work also in r13.x

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 10:22 PM, Ron Wheeler
rwhee...@artifact-software.com wrote:

Are you using it with a 12.04 or 13.xx?

What work is required to get it into 13.07?

Ron
On 30/09/2014 3:06 PM, Pierre Smits wrote:

Yes, I also have a vested interest in keeping this (PROJECTMGR) in

the
releases. It is part of our ORRTIZ:COM solution portfolio for our
customers
and we use it internally. And I have contributed to the improvement

of the

component.

We, at ORRTIZ:COM, even use an extension to the code base to ensure

that

also works for fixed price and internal projects. This extension

includes

generating the gl transactions regarding the cost price of each hour

registered regarding a project.

We also use the LDAP component to connect to our directory server

(Apache

Directory Server).

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler

rwheeler@artifact-software.

com

wrote:

It would be for me since it is one of the components that I want to

use.

Perhaps the more knowledgeable people might want to share a bit more

the background of the feature.

Is it in 12.xx.xx?

Is it currently in the 13.07 branch and therefor currently part of

the

13.07 versions that people have put in production or is it just in

the

trunk that people are putting into

Re: [VOTE] PROJECTMGR in upcoming release

Jacopo,

Back then there were already strong objections to excluding components from
the release. I recall that Hans also wanted to keep the SCRUM component in
the release, as well as there were proponents for BIRT and other components.

These are good additions to the feature set of OFBiz and may be in use
already by community members. It would be best that you solicit the advice
of the entire community before a decision on excluding components from any
release is taken. This affects more participants in this project than just
you and the committers.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 11:49 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

 Ok, got it.
 The release process that the OFBiz community is following is based on a
 feature freeze phase, that for the 13.07 branch started more than one year
 ago, during which only bug fixes are backported.
 This is done in order to stabilize the branch before an official release
 is done. Since the projectmgr component has never been part of the 13.07
 branch then it may be unsafe to include it now just before the release is
 issued. It would be better to discuss its inclusion in the upcoming new
 release branch where it could be stabilized and bug fixed.

 Regards,

 Jacopo

Re: [VOTE] PROJECTMGR in upcoming release

2014-09-30 Thread Mike

Why not deploy it as another hot-deploy component?   Is it considered a
core ERP component?

On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits pierre.sm...@gmail.com
wrote:

 Jacopo,

 Back then there were already strong objections to excluding components from
 the release. I recall that Hans also wanted to keep the SCRUM component in
 the release, as well as there were proponents for BIRT and other
 components.

 These are good additions to the feature set of OFBiz and may be in use
 already by community members. It would be best that you solicit the advice
 of the entire community before a decision on excluding components from any
 release is taken. This affects more participants in this project than just
 you and the committers.

 Regards,

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Tue, Sep 30, 2014 at 11:49 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:

  Ok, got it.
  The release process that the OFBiz community is following is based on a
  feature freeze phase, that for the 13.07 branch started more than one
 year
  ago, during which only bug fixes are backported.
  This is done in order to stabilize the branch before an official release
  is done. Since the projectmgr component has never been part of the
 13.07
  branch then it may be unsafe to include it now just before the release is
  issued. It would be better to discuss its inclusion in the upcoming new
  release branch where it could be stabilized and bug fixed.
 
  Regards,
 
  Jacopo

Re: [VOTE] PROJECTMGR in upcoming release

2014-09-30 Thread Ron Wheeler


It would be for me since it is one of the components that I want to use.

Perhaps the more knowledgeable people might want to share a bit more of 
the background of the feature.

Is it in 12.xx.xx?

Is it currently in the 13.07 branch and therefor currently part of the 
13.07 versions that people have put in production or is it just in the 
trunk that people are putting into production?


What are the issues that need to be addressed before it is stabilized 
and bug fixed?
Do any of these issues pose a significant risk to the stability of the 
rest of the functionality?


Is anyone using it in production? What are their opinions of the state 
of the code and the degree of risk?


Is anyone prepared to take on the task of getting it stabilized and bug 
fixed to a point where it can be safely included?

What is the estimate of the minimum effort required?

Ron

On 30/09/2014 9:58 AM, Mike wrote:

Why not deploy it as another hot-deploy component?   Is it considered a
core ERP component?

On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits pierre.sm...@gmail.com
wrote:


Jacopo,

Back then there were already strong objections to excluding components from
the release. I recall that Hans also wanted to keep the SCRUM component in
the release, as well as there were proponents for BIRT and other
components.

These are good additions to the feature set of OFBiz and may be in use
already by community members. It would be best that you solicit the advice
of the entire community before a decision on excluding components from any
release is taken. This affects more participants in this project than just
you and the committers.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 11:49 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:


Ok, got it.
The release process that the OFBiz community is following is based on a
feature freeze phase, that for the 13.07 branch started more than one

year

ago, during which only bug fixes are backported.
This is done in order to stabilize the branch before an official release
is done. Since the projectmgr component has never been part of the

13.07

branch then it may be unsafe to include it now just before the release is
issued. It would be better to discuss its inclusion in the upcoming new
release branch where it could be stabilized and bug fixed.

Regards,

Jacopo




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

Re: [VOTE] PROJECTMGR in upcoming release

2014-09-30 Thread Ted Byers

See below:

On Tue, Sep 30, 2014 at 9:58 AM, Mike mz4whee...@gmail.com wrote:

 Why not deploy it as another hot-deploy component?   Is it considered a
 core ERP component?


I do not know about whether or not it is 'core', but the idea of deploying
it as a hot-deploy component has merit.

As I read Jacopo's remarks, it isn't so much a concern about whether or not
the component in question ought to be included in OFBiz at all, but rather
the concern is of the risk of including it at a late date in the release
cycle (just before a scheduled release).  As a developer, I know there
would be major pushback by the development team against any manager asking
to include a new 'feature' shortly before a scheduled release.  We have a
feature freeze in a release cycle for a reason.  For any new feature, there
needs to be a dialog between at least the senior developers and the
management, and the users,  about what the feature is, how it ought to
work, c., and that is a dialog that can not be rushed if you want a good
product; if you work on adding a new feature even months before a release
date, I can guarantee it will not be well thought
out/designed/implemented.  Even if the component being considered at the
moment is 'reasonably' well conceived and much work has gone into
developing it, if it has never been part of the 13.07 release, including it
so close to the scheduled release is a recipe for 'problems', and possibly
some sleepless nights and ulcers for whoever has to make it work.  In my
shop, we have a whole separate system on which new and proposed features
are developed and tested thoroughly before that code is even considered for
inclusion in our production systems.  It is a test bed on which all
interested parties can see new features in operation, in the context of the
application, and learn about what is practicable and desirable.  Sometimes,
after working with it on dev, they see that trying to fully implement and
deploy the new feature would be foolish and unnecessary; and this before
major development effort has been invested.  And sometimes, we collectively
learn that the new feature is practicable and desirable, and at that point,
we already have a prototype that can be used to quickly develop it to a
point where it can be deployed to production.

Jacopo does say that It would be better to discuss its inclusion in the
upcoming new release branch where it could be stabilized and bug fixed.
Myself, I would take that a step further in suggesting, borrowing from
Mike's suggestion, that it ought to be available as something that can be
used in a hot-deploy sandbox as it were: a method that, conceptually
facilitates those interested in it to work with it, test in in their
release, c., but in such a way that it can not damage anything else in the
application.

It may be useful to look at how R handles these issues.  There is R-core,
and an R-core team, that is part of the main distribution (all packages
included in an installation of it), and then there is CRAN (similar in
concept to CPAN, for any Perl programmers out there - I hope it isn't
considered blasphemy to talk about Perl in this forum ;-)  ), to which all
members of the R community can contribute their packages; analogous to
components in the context of an application like OFBiz.  CRAN has a QA
protocol, which must be passed in order for an R package to be added to
CRAN; something that assures users that their system will not be trashed if
they instal a package available from CRAN.  And, sometimes, the R core team
decides that one of the packages on CRAN is so important and useful that
they decide to add it to core (this doesn't happen often, but it does
happen).  So then, in the context of OFBiz, the first question becomes, can
the hot-deploy support be used in a manner similar to a snadbox that
protext the rest of the system from badly behaved code (NB: I am not
implying anything about the code in the component in question now, but
rather thinking in general terms for any new component anyone may want to
contribute)?  And then, the question becomes, what protocol can be used for
promoting components from the 'sandbox' to incorporation into the 'core
release'; whatever you want to call it?

Cheers

Ted


 On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits pierre.sm...@gmail.com
 wrote:

  Jacopo,
 
  Back then there were already strong objections to excluding components
 from
  the release. I recall that Hans also wanted to keep the SCRUM component
 in
  the release, as well as there were proponents for BIRT and other
  components.
 
  These are good additions to the feature set of OFBiz and may be in use
  already by community members. It would be best that you solicit the
 advice
  of the entire community before a decision on excluding components from
 any
  release is taken. This affects more participants in this project than
 just
  you and the committers.
 
  Regards,
 
  Pierre Smits
 
  *ORRTIZ.COM http://www.orrtiz.com*
  Services

Re: [VOTE] PROJECTMGR in upcoming release

Ron, All,

For an overview of special purpose components included in the 12.x
releases, see
http://svn.apache.org/viewvc/ofbiz/branches/release12.04/specialpurpose/

For an overview of the special purpose components in the 13.x branch, see:
http://svn.apache.org/viewvc/ofbiz/branches/release13.07/specialpurpose/

Regards,


Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

 It would be for me since it is one of the components that I want to use.

 Perhaps the more knowledgeable people might want to share a bit more of
 the background of the feature.
 Is it in 12.xx.xx?

 Is it currently in the 13.07 branch and therefor currently part of the
 13.07 versions that people have put in production or is it just in the
 trunk that people are putting into production?

 What are the issues that need to be addressed before it is stabilized and
 bug fixed?
 Do any of these issues pose a significant risk to the stability of the
 rest of the functionality?

 Is anyone using it in production? What are their opinions of the state of
 the code and the degree of risk?

 Is anyone prepared to take on the task of getting it stabilized and bug
 fixed to a point where it can be safely included?
 What is the estimate of the minimum effort required?

 Ron


 On 30/09/2014 9:58 AM, Mike wrote:

 Why not deploy it as another hot-deploy component?   Is it considered a
 core ERP component?

 On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits pierre.sm...@gmail.com
 wrote:

  Jacopo,

 Back then there were already strong objections to excluding components
 from
 the release. I recall that Hans also wanted to keep the SCRUM component
 in
 the release, as well as there were proponents for BIRT and other
 components.

 These are good additions to the feature set of OFBiz and may be in use
 already by community members. It would be best that you solicit the
 advice
 of the entire community before a decision on excluding components from
 any
 release is taken. This affects more participants in this project than
 just
 you and the committers.

 Regards,

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Tue, Sep 30, 2014 at 11:49 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:

  Ok, got it.
 The release process that the OFBiz community is following is based on a
 feature freeze phase, that for the 13.07 branch started more than one

 year

 ago, during which only bug fixes are backported.
 This is done in order to stabilize the branch before an official release
 is done. Since the projectmgr component has never been part of the

 13.07

 branch then it may be unsafe to include it now just before the release
 is
 issued. It would be better to discuss its inclusion in the upcoming new
 release branch where it could be stabilized and bug fixed.

 Regards,

 Jacopo



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

Re: [VOTE] PROJECTMGR in upcoming release

Yes, I also have a vested interest in keeping this (PROJECTMGR) in the
releases. It is part of our ORRTIZ:COM solution portfolio for our customers
and we use it internally. And I have contributed to the improvement of the
component.

We, at ORRTIZ:COM, even use an extension to the code base to ensure that it
also works for fixed price and internal projects. This extension includes
generating the gl transactions regarding the cost price of each hour
registered regarding a project.

We also use the LDAP component to connect to our directory server (Apache
Directory Server).

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

 It would be for me since it is one of the components that I want to use.

 Perhaps the more knowledgeable people might want to share a bit more of
 the background of the feature.
 Is it in 12.xx.xx?

 Is it currently in the 13.07 branch and therefor currently part of the
 13.07 versions that people have put in production or is it just in the
 trunk that people are putting into production?

 What are the issues that need to be addressed before it is stabilized and
 bug fixed?
 Do any of these issues pose a significant risk to the stability of the
 rest of the functionality?

 Is anyone using it in production? What are their opinions of the state of
 the code and the degree of risk?

 Is anyone prepared to take on the task of getting it stabilized and bug
 fixed to a point where it can be safely included?
 What is the estimate of the minimum effort required?

 Ron


 On 30/09/2014 9:58 AM, Mike wrote:

 Why not deploy it as another hot-deploy component?   Is it considered a
 core ERP component?

 On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits pierre.sm...@gmail.com
 wrote:

  Jacopo,

 Back then there were already strong objections to excluding components
 from
 the release. I recall that Hans also wanted to keep the SCRUM component
 in
 the release, as well as there were proponents for BIRT and other
 components.

 These are good additions to the feature set of OFBiz and may be in use
 already by community members. It would be best that you solicit the
 advice
 of the entire community before a decision on excluding components from
 any
 release is taken. This affects more participants in this project than
 just
 you and the committers.

 Regards,

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Tue, Sep 30, 2014 at 11:49 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:

  Ok, got it.
 The release process that the OFBiz community is following is based on a
 feature freeze phase, that for the 13.07 branch started more than one

 year

 ago, during which only bug fixes are backported.
 This is done in order to stabilize the branch before an official release
 is done. Since the projectmgr component has never been part of the

 13.07

 branch then it may be unsafe to include it now just before the release
 is
 issued. It would be better to discuss its inclusion in the upcoming new
 release branch where it could be stabilized and bug fixed.

 Regards,

 Jacopo



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

Re: [VOTE] PROJECTMGR in upcoming release

2014-09-30 Thread Ron Wheeler


It seems to be actively maintained on the trunk.
Is it just a matter of copying it to the release branch?

Ron

On 30/09/2014 2:20 PM, Pierre Smits wrote:

Ron, All,

For an overview of special purpose components included in the 12.x
releases, see
http://svn.apache.org/viewvc/ofbiz/branches/release12.04/specialpurpose/

For an overview of the special purpose components in the 13.x branch, see:
http://svn.apache.org/viewvc/ofbiz/branches/release13.07/specialpurpose/

Regards,


Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler rwhee...@artifact-software.com

wrote:
It would be for me since it is one of the components that I want to use.

Perhaps the more knowledgeable people might want to share a bit more of
the background of the feature.
Is it in 12.xx.xx?

Is it currently in the 13.07 branch and therefor currently part of the
13.07 versions that people have put in production or is it just in the
trunk that people are putting into production?

What are the issues that need to be addressed before it is stabilized and
bug fixed?
Do any of these issues pose a significant risk to the stability of the
rest of the functionality?

Is anyone using it in production? What are their opinions of the state of
the code and the degree of risk?

Is anyone prepared to take on the task of getting it stabilized and bug
fixed to a point where it can be safely included?
What is the estimate of the minimum effort required?

Ron


On 30/09/2014 9:58 AM, Mike wrote:


Why not deploy it as another hot-deploy component?   Is it considered a
core ERP component?

On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits pierre.sm...@gmail.com
wrote:

  Jacopo,

Back then there were already strong objections to excluding components
from
the release. I recall that Hans also wanted to keep the SCRUM component
in
the release, as well as there were proponents for BIRT and other
components.

These are good additions to the feature set of OFBiz and may be in use
already by community members. It would be best that you solicit the
advice
of the entire community before a decision on excluding components from
any
release is taken. This affects more participants in this project than
just
you and the committers.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 11:49 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

  Ok, got it.

The release process that the OFBiz community is following is based on a
feature freeze phase, that for the 13.07 branch started more than one


year


ago, during which only bug fixes are backported.
This is done in order to stabilize the branch before an official release
is done. Since the projectmgr component has never been part of the


13.07


branch then it may be unsafe to include it now just before the release
is
issued. It would be better to discuss its inclusion in the upcoming new
release branch where it could be stabilized and bug fixed.

Regards,

Jacopo



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





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

Re: [VOTE] PROJECTMGR in upcoming release

2014-09-30 Thread Ron Wheeler


Are you using it with a 12.04 or 13.xx?
What work is required to get it into 13.07?

Ron
On 30/09/2014 3:06 PM, Pierre Smits wrote:

Yes, I also have a vested interest in keeping this (PROJECTMGR) in the
releases. It is part of our ORRTIZ:COM solution portfolio for our customers
and we use it internally. And I have contributed to the improvement of the
component.

We, at ORRTIZ:COM, even use an extension to the code base to ensure that it
also works for fixed price and internal projects. This extension includes
generating the gl transactions regarding the cost price of each hour
registered regarding a project.

We also use the LDAP component to connect to our directory server (Apache
Directory Server).

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 4:39 PM, Ron Wheeler rwhee...@artifact-software.com

wrote:
It would be for me since it is one of the components that I want to use.

Perhaps the more knowledgeable people might want to share a bit more of
the background of the feature.
Is it in 12.xx.xx?

Is it currently in the 13.07 branch and therefor currently part of the
13.07 versions that people have put in production or is it just in the
trunk that people are putting into production?

What are the issues that need to be addressed before it is stabilized and
bug fixed?
Do any of these issues pose a significant risk to the stability of the
rest of the functionality?

Is anyone using it in production? What are their opinions of the state of
the code and the degree of risk?

Is anyone prepared to take on the task of getting it stabilized and bug
fixed to a point where it can be safely included?
What is the estimate of the minimum effort required?

Ron


On 30/09/2014 9:58 AM, Mike wrote:


Why not deploy it as another hot-deploy component?   Is it considered a
core ERP component?

On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits pierre.sm...@gmail.com
wrote:

  Jacopo,

Back then there were already strong objections to excluding components
from
the release. I recall that Hans also wanted to keep the SCRUM component
in
the release, as well as there were proponents for BIRT and other
components.

These are good additions to the feature set of OFBiz and may be in use
already by community members. It would be best that you solicit the
advice
of the entire community before a decision on excluding components from
any
release is taken. This affects more participants in this project than
just
you and the committers.

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Tue, Sep 30, 2014 at 11:49 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

  Ok, got it.

The release process that the OFBiz community is following is based on a
feature freeze phase, that for the 13.07 branch started more than one


year


ago, during which only bug fixes are backported.
This is done in order to stabilize the branch before an official release
is done. Since the projectmgr component has never been part of the


13.07


branch then it may be unsafe to include it now just before the release
is
issued. It would be better to discuss its inclusion in the upcoming new
release branch where it could be stabilized and bug fixed.

Regards,

Jacopo



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





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

Re: [VOTE] PROJECTMGR in upcoming release