OFBiz › OFBiz - User

Inclusion of special purpose apps in demo-stable

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Pierre Smits

Inclusion of special purpose apps in demo-stable

Jacques,

I remember that conversation. Wouldn't it have been better to discuss that
in the (bigger) user mailing list?

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:54 AM, Jacques Le Roux <
[hidden email]> wrote:

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