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 <[email protected]>
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 <[email protected]>
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 <
[email protected]> 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 <
[email protected] <mailto:[email protected]>>
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 <
[email protected]
<mailto:[email protected]>> 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]
<mailto:[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://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]
<mailto:[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://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] <mailto:[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://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]
<mailto:[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
