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
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
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
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
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
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
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
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 (
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
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
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
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
.
--
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.
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
://ofbiz.135035.n4.nabble.com/Re-VOTE-PROJECTMGR-in-upcoming-release-tp4656231p4656351.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
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.
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.
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
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
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
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
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
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:
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
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
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
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
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
44 matches
Mail list logo
