Re: [VOTE] PROJECTMGR in upcoming release

[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 <[hidden email]>
>> 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 <[hidden email]>
>>>> 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 <
>>>>>> [hidden email]> 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 <
>>>>>>>>> [hidden email] <mailto:rwheeler@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 <
>>>>>>>>>          [hidden email]
>>>>>>>>> <mailto:[hidden email]>> 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
>>>>>>>>>              <[hidden email]
>>>>>>>>> <mailto:[hidden email]>>
>>>>>>>>>              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 <
>>>>>>>>> [hidden email]
>>>>>>>>> <mailto:[hidden email]>> 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 <
>>>>>>>>>
>>>>>>>>>              [hidden email] <mailto:[hidden email]>>
>>>>>>>>>
>>>>>>>>>                                      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 <
>>>>>>>>> [hidden email]
>>>>>>>>> <mailto:[hidden email]>>
>>>>>>>>>                                          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: [hidden email]
>>> skype: ronaldmwheeler
>>> phone: [phone], ext 102
>>>
>>>
>

[Pierre Smits]

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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> >> 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 <[hidden email]
> >
> >> 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 <
> >> [hidden email]> 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 <
> >> [hidden email] <mailto:[hidden email]>>
> >> 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 <
> >>>>>>>>>       [hidden email]
> >>>>>>>>>       <mailto:[hidden email]>> 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
> >>>>>>>>>           <[hidden email]
> >>>>>>>>>           <mailto:[hidden email]>>
> >>>>>>>>>           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 <
> >>>>>>>>>                   [hidden email]
> >>>>>>>>> <mailto:[hidden email]>> 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 <
> >>>>>>>>>
> >>>>>>>>>           [hidden email] <mailto:[hidden email]
> >>
> >>>>>>>>>
> >>>>>>>>>                                   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 <
> >>>>>>>>> [hidden email]
> >>>>>>>>> <mailto:[hidden email]>>
> >>>>>>>>>                                       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: [hidden email]
> >>> skype: ronaldmwheeler
> >>> phone: [phone], ext 102
> >>>
> >>
> >>
>
>

[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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 <
>>>>>>>>         [hidden email]
>>>>>>>>         <mailto:[hidden email]>> 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
>>>>>>>>             <[hidden email]
>>>>>>>>             <mailto:[hidden email]>>
>>>>>>>>             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 <
>>>>>>>>                     [hidden email]
>>>>>>>> <mailto:[hidden email]>> 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 <
>>>>>>>>
>>>>>>>>             [hidden email] <mailto:[hidden email]>>
>>>>>>>>
>>>>>>>>                                     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 <
>>>>>>>> [hidden email]
>>>>>>>> <mailto:[hidden email]>>
>>>>>>>>                                         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: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]>
>>> 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 <[hidden email]>
>>> 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 <
>>> [hidden email]> 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 <
>>> [hidden email] <mailto:[hidden email]>>
>>> 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 <
>>>>>>>>>>        [hidden email]
>>>>>>>>>>        <mailto:[hidden email]>> 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
>>>>>>>>>>            <[hidden email]
>>>>>>>>>>            <mailto:[hidden email]>>
>>>>>>>>>>            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 <
>>>>>>>>>>                    [hidden email]
>>>>>>>>>> <mailto:[hidden email]>> 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 <
>>>>>>>>>>
>>>>>>>>>>            [hidden email] <mailto:[hidden email]>>
>>>>>>>>>>
>>>>>>>>>>                                    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 <
>>>>>>>>>> [hidden email]
>>>>>>>>>> <mailto:[hidden email]>>
>>>>>>>>>>                                        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: [hidden email]
>>>> skype: ronaldmwheeler
>>>> phone: [phone], ext 102
>>>>
>>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Pierre Smits]

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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]>
>>>> 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 <[hidden email]
>>>>>> >
>>>>>>
>>>>> 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 <
>>>>>>>>
>>>>>>> [hidden email]> 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 <
>>>>>>>>>>>
>>>>>>>>>> [hidden email] <mailto:rwheeler@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 <
>>>>>>>>>>>        [hidden email]
>>>>>>>>>>>        <mailto:[hidden email]>> 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
>>>>>>>>>>>            <[hidden email]
>>>>>>>>>>>            <mailto:[hidden email]>>
>>>>>>>>>>>            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
>>>>>>>>>>> <
>>>>>>>>>>>                    [hidden email]
>>>>>>>>>>> <mailto:[hidden email]>> 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 <
>>>>>>>>>>>
>>>>>>>>>>>            [hidden email] <mailto:[hidden email]
>>>>>>>>>>> >>
>>>>>>>>>>>
>>>>>>>>>>>                                    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 <
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> <mailto:[hidden email]>>
>>>>>>>>>>>                                        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: [hidden email]
>>>>> skype: ronaldmwheeler
>>>>> phone: [phone], ext 102
>>>>>
>>>>>
>>>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>