"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 <[email protected]>
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 <
[email protected]> 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 <[email protected]>
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 <
[email protected]> 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: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
