Summary of ApacheCon-Eu conference "Why ofbiz-extra"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Summary of ApacheCon-Eu conference "Why ofbiz-extra"

olivier.heintz Neogia.org
ApacheCon-Eu presentation is now available,
http://archive.apachecon.com/eu2012/presentations/07-Wednesday/PR-Community/aceu-2012-ofbizextra-addons_what-constrains-for-each-repository.pdf


I propose below a short summary (only the main points) to be able to
start community discussion.

I will do a second mail for comments about this presentation.

Agenda :
======
- Why to use OFBiz-extra rather than to include it in Apache-OFBiz?
- the ofbizextra-addons Goals
- Rules and Constraints by Repository
- Process to change
- Conclusions

Why to use OFBiz-extra rather than to include it in Apache-OFBiz?
=========================================
- Slim-down process in Apache-OFBiz project
- Several technologies for the same function
Ex : jasperReport, Birt, …
- Licence
Ex : GPL
- Personal decision versus Apache-OFBiz PMC decision
- Work in progress
- OOTB solutions for dedicated Business

ofbizextra-addons Goals
===============
- Facilitate and simplify :
* Contribution to OFBiz
* Using / Testing added functions
* Community and/or OFBiz-committer validation
- Increase :
* Quality and use of Best Practice
* OFBiz functionalities without weighing down kernel
* Propose OOTB dedicated solutions for users

Rules and Constraints by Repository
=======================
- 3 repository
- ofbiz-extra-addons-dev
* This project is open for all contributors who want to create or
maintain apache-ofbiz addons.
* This project has no quality or best practice control, each contributor
should try to do the best he can.
* When a user uses an existing addon in this repository, he should
assume risks, but but in many cases it will help him.
- ofbiz-extra-addons-incubator
* This project is open for all Apache-OFBiz addons that should become :
+ part of ofbiz addons labeled "Quality" repository (ofbizextra-addons),
+ or part of Apache ofbiz project.
* Addons of this project are in a Quality, Best Practice evaluation and
enhancement.
* There is, at least, one organization / person that is involved to
solve bugs or to offer support services for this addon.
- ofbiz-extra-addons
* Repository of the addons labeled "Quality"
* In the future, a similar repository can be created as an Apache-OFBiz
sub-project (for addons with Apache2 licence)
* There is, at least, one organization / person that is committed to
offer support services for this addon.
* Addons
+ Have a complete user help
+ are included in a Continuous Integration Job :
= Installation test
= Unit test : Junit
= Functional test : Selenium

Addon Quality status page
(http://code.google.com/a/apache-extras.org/p/ofbiz-extra-addons-incubator/wiki/modelAddonQuality)
=================
- Update history
* contributor, date, version, indicator, description
* reviewer, date, version, indicator, description
- Base Files
* add-on.xml, date, version, status, indicator
* maintainer in add-on.xml, date, version, status, indicator
* ivy.xml, date, version, status, indicator
* addon help (English), date, version, status, indicator
* jenkins job, date, version, status, indicator
- User Help File
* writing, date, version, status, indicator
* review and test, date, version, status, indicator
- Details
* Entity - Field
+ Entity, FieldName, Label, Field Description, version, indicator
* Service
+ ServiceName, description, Junit, version, indicator
* Portlet
+ PortletName, help, SeedData, parameters, security, selenium, version
indicator

Conditions to be in Incubator
==================
- The minimum is :
* add-on.xml and ivy.xml correct
* a jenkins job for install testing
* addon help wiki page finished
* Quality status wiki page created with all boxes
* One review for User Help section
- Authorized to commit only for
* Addon maintainer

Condition to return to dev
================
- More than 5 consecutive weeks with only failing install test jobs
- No answer for user help questions
* Answers can be an assistance proposal
* and If the user help is not completed
- No answer from the maintainer
* It's possible to change the addon maintainer if other people do it
- New function posted without user help or addon goal change
* Quality regression
- No support for a new future release-branch
* Ofbiz trunk branch support is not mandatory

Conditions to become :
==============
- Part of Apache-ofbiz
* Rules of Apache-OFBiz
+ The quality status will help the committer to assess the contribution
+ The evaluation in the incubator can be done by other people than the
committer, so as to help the apache-ofbiz committer
- In the ofbiz-addons repository labeled “Quality”
* All Quality status page items are OK
* 5 consecutive weeks with at least one day per week with a successful
jenkins job (install+unit+functional)
* 2 other addon maintainers ready to become “maintainer deputy” (in two
other companies)

Condition to “go back” to:
================
- Incubator
* Quality regression:
+ New function posted without user help or addon goal change
+ New service without Junit test
+ New portlet without selenium test
- Dev
* More than 5 consecutive weeks with only failing
“install-unit-functional test” jobs
- Go back or revert commit in ofbizextra-addons and commit new addon in
dev or incubator

What exist, what is ready
================
| addonmanager | ready to use for experienced developer, not for
beginner or end user | 1/5 |
| adr Addon repository manager | operational, little problem with google
code access | 4/5 |
| ofbiz-extra-addons-dev | Exists, contains 4 addons for OFBiz
PortletWidget branch | 4/5 |
| ofbiz-extra-addons-incubator | Exists, work in progress, not yet an
addon, the first one will be adm-gui | 2/5 |
| ofbiz-extra-addons | not created yet | 0/5 |
| user help engine | Current ofbiz help system is usable, new help
system is better |
| even if there are some functionalities to finish | 3/5 |
| addon help | operational with current ofbiz help system, not with the
new one | 4/5 |
| quality status page per addon | exists but manual update could be too
expensive to be usable | 3/5 |
| Junit engine in OFBiz | exists and operational in jenkins environment
| 5/5 |
| selenium engine in OFBiz | exists, but not integrated in ofbiz and
still with random errors |
| with httpunit-webdriver | 2/5 |
| ofbizextra jenkin server | not available yet, but jenkins.neogia.org
can be used for the first addons | 1/5 |


Conclusions
=======
- Everything is ready to facilitate contributions
* Small ones and larger ones
* Technical or/and functional
* One function or a Solution
- Everything is ready to continue the Apache-OFBiz
* Slim-down process
+ ex: Birt
- Everything is ready to start an improvement in quality


Reply | Threaded
Open this post in threaded view
|

Re: Summary of ApacheCon-Eu conference "Why ofbiz-extra"

olivier.heintz Neogia.org
The mains important point are :
- This is one way to facilitate Contribution to OFBiz  *AND* Quality
enhancement
- Share contribution, even if it's not for all ofbiz user, even if it
not follow all current bests practices,  can help
- We need to have a clear definition of what are the Quality criteria
fro Apache-OFBiz
- We need to have a clear process for contribution evaluation and status
and life process

The main comment done by the attendees :
- It's very important to have a addon repository in Apache-OFBiz

The next steps should be :
- to write 1,2 or 3 wiki pages for OFBiz choices (writing in a consensus
way);
- to give visibility on new help integration
- to give visibility on functional (or user-interface) test solution
adopt by OFBiz
- to start a process on addon manager evaluation
- to start to give visibility to ofbiz-extra




Le 27/11/2012 11:28, olivier Heintz a écrit :

> ApacheCon-Eu presentation is now available,
> http://archive.apachecon.com/eu2012/presentations/07-Wednesday/PR-Community/aceu-2012-ofbizextra-addons_what-constrains-for-each-repository.pdf
>
>
> I propose below a short summary (only the main points) to be able to
> start community discussion.
>
> I will do a second mail for comments about this presentation.
>
> Agenda :
> ======
> - Why to use OFBiz-extra rather than to include it in Apache-OFBiz?
> - the ofbizextra-addons Goals
> - Rules and Constraints by Repository
> - Process to change
> - Conclusions
>
> Why to use OFBiz-extra rather than to include it in Apache-OFBiz?
> =========================================
> - Slim-down process in Apache-OFBiz project
> - Several technologies for the same function
> Ex : jasperReport, Birt, …
> - Licence
> Ex : GPL
> - Personal decision versus Apache-OFBiz PMC decision
> - Work in progress
> - OOTB solutions for dedicated Business
>
> ofbizextra-addons Goals
> ===============
> - Facilitate and simplify :
> * Contribution to OFBiz
> * Using / Testing added functions
> * Community and/or OFBiz-committer validation
> - Increase :
> * Quality and use of Best Practice
> * OFBiz functionalities without weighing down kernel
> * Propose OOTB dedicated solutions for users
>
> Rules and Constraints by Repository
> =======================
> - 3 repository
> - ofbiz-extra-addons-dev
> * This project is open for all contributors who want to create or
> maintain apache-ofbiz addons.
> * This project has no quality or best practice control, each contributor
> should try to do the best he can.
> * When a user uses an existing addon in this repository, he should
> assume risks, but but in many cases it will help him.
> - ofbiz-extra-addons-incubator
> * This project is open for all Apache-OFBiz addons that should become :
> + part of ofbiz addons labeled "Quality" repository (ofbizextra-addons),
> + or part of Apache ofbiz project.
> * Addons of this project are in a Quality, Best Practice evaluation and
> enhancement.
> * There is, at least, one organization / person that is involved to
> solve bugs or to offer support services for this addon.
> - ofbiz-extra-addons
> * Repository of the addons labeled "Quality"
> * In the future, a similar repository can be created as an Apache-OFBiz
> sub-project (for addons with Apache2 licence)
> * There is, at least, one organization / person that is committed to
> offer support services for this addon.
> * Addons
> + Have a complete user help
> + are included in a Continuous Integration Job :
> = Installation test
> = Unit test : Junit
> = Functional test : Selenium
>
> Addon Quality status page
> (http://code.google.com/a/apache-extras.org/p/ofbiz-extra-addons-incubator/wiki/modelAddonQuality)
> =================
> - Update history
> * contributor, date, version, indicator, description
> * reviewer, date, version, indicator, description
> - Base Files
> * add-on.xml, date, version, status, indicator
> * maintainer in add-on.xml, date, version, status, indicator
> * ivy.xml, date, version, status, indicator
> * addon help (English), date, version, status, indicator
> * jenkins job, date, version, status, indicator
> - User Help File
> * writing, date, version, status, indicator
> * review and test, date, version, status, indicator
> - Details
> * Entity - Field
> + Entity, FieldName, Label, Field Description, version, indicator
> * Service
> + ServiceName, description, Junit, version, indicator
> * Portlet
> + PortletName, help, SeedData, parameters, security, selenium, version
> indicator
>
> Conditions to be in Incubator
> ==================
> - The minimum is :
> * add-on.xml and ivy.xml correct
> * a jenkins job for install testing
> * addon help wiki page finished
> * Quality status wiki page created with all boxes
> * One review for User Help section
> - Authorized to commit only for
> * Addon maintainer
>
> Condition to return to dev
> ================
> - More than 5 consecutive weeks with only failing install test jobs
> - No answer for user help questions
> * Answers can be an assistance proposal
> * and If the user help is not completed
> - No answer from the maintainer
> * It's possible to change the addon maintainer if other people do it
> - New function posted without user help or addon goal change
> * Quality regression
> - No support for a new future release-branch
> * Ofbiz trunk branch support is not mandatory
>
> Conditions to become :
> ==============
> - Part of Apache-ofbiz
> * Rules of Apache-OFBiz
> + The quality status will help the committer to assess the contribution
> + The evaluation in the incubator can be done by other people than the
> committer, so as to help the apache-ofbiz committer
> - In the ofbiz-addons repository labeled “Quality”
> * All Quality status page items are OK
> * 5 consecutive weeks with at least one day per week with a successful
> jenkins job (install+unit+functional)
> * 2 other addon maintainers ready to become “maintainer deputy” (in two
> other companies)
>
> Condition to “go back” to:
> ================
> - Incubator
> * Quality regression:
> + New function posted without user help or addon goal change
> + New service without Junit test
> + New portlet without selenium test
> - Dev
> * More than 5 consecutive weeks with only failing
> “install-unit-functional test” jobs
> - Go back or revert commit in ofbizextra-addons and commit new addon in
> dev or incubator
>
> What exist, what is ready
> ================
> | addonmanager | ready to use for experienced developer, not for
> beginner or end user | 1/5 |
> | adr Addon repository manager | operational, little problem with google
> code access | 4/5 |
> | ofbiz-extra-addons-dev | Exists, contains 4 addons for OFBiz
> PortletWidget branch | 4/5 |
> | ofbiz-extra-addons-incubator | Exists, work in progress, not yet an
> addon, the first one will be adm-gui | 2/5 |
> | ofbiz-extra-addons | not created yet | 0/5 |
> | user help engine | Current ofbiz help system is usable, new help
> system is better |
> | even if there are some functionalities to finish | 3/5 |
> | addon help | operational with current ofbiz help system, not with the
> new one | 4/5 |
> | quality status page per addon | exists but manual update could be too
> expensive to be usable | 3/5 |
> | Junit engine in OFBiz | exists and operational in jenkins environment
> | 5/5 |
> | selenium engine in OFBiz | exists, but not integrated in ofbiz and
> still with random errors |
> | with httpunit-webdriver | 2/5 |
> | ofbizextra jenkin server | not available yet, but jenkins.neogia.org
> can be used for the first addons | 1/5 |
>
>
> Conclusions
> =======
> - Everything is ready to facilitate contributions
> * Small ones and larger ones
> * Technical or/and functional
> * One function or a Solution
> - Everything is ready to continue the Apache-OFBiz
> * Slim-down process
> + ex: Birt
> - Everything is ready to start an improvement in quality
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Summary of ApacheCon-Eu conference "Why ofbiz-extra"

Jacques Le Roux
Administrator
In reply to this post by olivier.heintz Neogia.org
From: "olivier Heintz" <[hidden email]>

> ApacheCon-Eu presentation is now available,
> http://archive.apachecon.com/eu2012/presentations/07-Wednesday/PR-Community/aceu-2012-ofbizextra-addons_what-constrains-for-each-repository.pdf
>
>
> I propose below a short summary (only the main points) to be able to
> start community discussion.
>
> I will do a second mail for comments about this presentation.
>
> Agenda :
> ======
> - Why to use OFBiz-extra rather than to include it in Apache-OFBiz?
> - the ofbizextra-addons Goals
> - Rules and Constraints by Repository
> - Process to change
> - Conclusions
>
> Why to use OFBiz-extra rather than to include it in Apache-OFBiz?
> =========================================
> - Slim-down process in Apache-OFBiz project
> - Several technologies for the same function
> Ex : jasperReport, Birt, …
> - Licence
> Ex : GPL
> - Personal decision versus Apache-OFBiz PMC decision
> - Work in progress
> - OOTB solutions for dedicated Business

Sounds like good reasons to me.

> ofbizextra-addons Goals
> ===============
> - Facilitate and simplify :
> * Contribution to OFBiz
> * Using / Testing added functions
> * Community and/or OFBiz-committer validation
> - Increase :
> * Quality and use of Best Practice
> * OFBiz functionalities without weighing down kernel
> * Propose OOTB dedicated solutions for users

More tests should be done by the community before adopting ofbizextra-addons for Apache OFBiz Extras
But from my early tests, and knowing the Neogia community experience with addons, I think all these goals qualify.


> Rules and Constraints by Repository
> =======================
> - 3 repository

From what I already learned (very few) from addons, these must be svn repos.
It would not be at the ASF because of possible license issues, so where will they be? How reliable will they be or should they be? etc.
Also we could have an entry in the ASF repo, under https://svn.apache.org/repos/asf/ofbiz if the addons are ASL2 licensed. But this would NOT mean, except if we agree otherwise, that the addons there are reviewed "guaranteed" by the OFBiz team. Anyway from an official POV *only released products are official*. I mean those here http://ofbiz.apache.org/download.html

> - ofbiz-extra-addons-dev
> * This project is open for all contributors who want to create or
> maintain apache-ofbiz addons.
> * This project has no quality or best practice control, each contributor
> should try to do the best he can.
> * When a user uses an existing addon in this repository, he should
> assume risks, but but in many cases it will help him.

+1

> - ofbiz-extra-addons-incubator
> * This project is open for all Apache-OFBiz addons that should become :
> + part of ofbiz addons labeled "Quality" repository (ofbizextra-addons),
> + or part of Apache ofbiz project.
> * Addons of this project are in a Quality, Best Practice evaluation and
> enhancement.
> * There is, at least, one organization / person that is involved to
> solve bugs or to offer support services for this addon.

I wondered how this would be "enforced" but ok it's explained below in conditions.

> - ofbiz-extra-addons
> * Repository of the addons labeled "Quality"
> * In the future, a similar repository can be created as an Apache-OFBiz
> sub-project (for addons with Apache2 licence)

Yes, as discussed above IMO. Maybe not in a 1st step, but possibly when things will have settled down...

> * There is, at least, one organization / person that is committed to
> offer support services for this addon.
> * Addons
> + Have a complete user help
> + are included in a Continuous Integration Job :
> = Installation test
> = Unit test : Junit
> = Functional test : Selenium

What I fear (even with the conditions below) is the admin work (understand paper-work) related with these "steps" (not real steps since you can choose to stay in the dev eternally). I mean how to guarantee things/states related to conditions? Who will (officially, think conflicts) do it?
 
> Addon Quality status page
> (http://code.google.com/a/apache-extras.org/p/ofbiz-extra-addons-incubator/wiki/modelAddonQuality)

> =================
> - Update history
> * contributor, date, version, indicator, description
> * reviewer, date, version, indicator, description

> - Base Files
> * add-on.xml, date, version, status, indicator
> * maintainer in add-on.xml, date, version, status, indicator
> * ivy.xml, date, version, status, indicator
> * addon help (English), date, version, status, indicator
> * jenkins job, date, version, status, indicator

> - User Help File
> * writing, date, version, status, indicator
> * review and test, date, version, status, indicator

> - Details
> * Entity - Field
> + Entity, FieldName, Label, Field Description, version, indicator
> * Service
> + ServiceName, description, Junit, version, indicator
> * Portlet
> + PortletName, help, SeedData, parameters, security, selenium, version
> indicator

> Conditions to be in Incubator
> ==================
> - The minimum is :
> * add-on.xml and ivy.xml correct
> * a jenkins job for install testing
> * addon help wiki page finished
> * Quality status wiki page created with all boxes
> * One review for User Help section
> - Authorized to commit only for
> * Addon maintainer
>

> Condition to return to dev
> ================
> - More than 5 consecutive weeks with only failing install test jobs
> - No answer for user help questions
> * Answers can be an assistance proposal
> * and If the user help is not completed
> - No answer from the maintainer
> * It's possible to change the addon maintainer if other people do it
> - New function posted without user help or addon goal change
> * Quality regression
> - No support for a new future release-branch
> * Ofbiz trunk branch support is not mandatory


> Conditions to become :
> ==============
> - Part of Apache-ofbiz
> * Rules of Apache-OFBiz
> + The quality status will help the committer to assess the contribution
> + The evaluation in the incubator can be done by other people than the
> committer, so as to help the apache-ofbiz committer

BIG +1

> - In the ofbiz-addons repository labeled “Quality”
> * All Quality status page items are OK
> * 5 consecutive weeks with at least one day per week with a successful
> jenkins job (install+unit+functional)
> * 2 other addon maintainers ready to become “maintainer deputy” (in two
> other companies)

> Condition to “go back” to:
> ================
> - Incubator
> * Quality regression:
> + New function posted without user help or addon goal change
> + New service without Junit test
> + New portlet without selenium test
> - Dev
> * More than 5 consecutive weeks with only failing
> “install-unit-functional test” jobs
> - Go back or revert commit in ofbizextra-addons and commit new addon in
> dev or incubator

 

> What exist, what is ready
> ================
> | addonmanager | ready to use for experienced developer, not for
> beginner or end user | 1/5 |
> | adr Addon repository manager | operational, little problem with google
> code access | 4/5 |
> | ofbiz-extra-addons-dev | Exists, contains 4 addons for OFBiz
> PortletWidget branch | 4/5 |
> | ofbiz-extra-addons-incubator | Exists, work in progress, not yet an
> addon, the first one will be adm-gui | 2/5 |
> | ofbiz-extra-addons | not created yet | 0/5 |
> | user help engine | Current ofbiz help system is usable, new help
> system is better |
> | even if there are some functionalities to finish | 3/5 |
> | addon help | operational with current ofbiz help system, not with the
> new one | 4/5 |
> | quality status page per addon | exists but manual update could be too
> expensive to be usable | 3/5 |
> | Junit engine in OFBiz | exists and operational in jenkins environment
> | 5/5 |
> | selenium engine in OFBiz | exists, but not integrated in ofbiz and
> still with random errors |
> | with httpunit-webdriver | 2/5 |
> | ofbizextra jenkin server | not available yet, but jenkins.neogia.org
> can be used for the first addons | 1/5 |

So all this ius currently supported by "Neogia  servers", right?
 

> Conclusions
> =======
> - Everything is ready to facilitate contributions
> * Small ones and larger ones
> * Technical or/and functional
> * One function or a Solution
> - Everything is ready to continue the Apache-OFBiz
> * Slim-down process
> + ex: Birt
> - Everything is ready to start an improvement in quality

Nice introduction, thanks Olivier!

Jacques
Reply | Threaded
Open this post in threaded view
|

Re: Summary of ApacheCon-Eu conference "Why ofbiz-extra"

David E. Jones-2
In reply to this post by olivier.heintz Neogia.org

With all of these constraints, what would be the point of using extras projects?

Please consider that these QA, documentation, etc constraints even exist and are not enforced for OFBiz itself... and are clearly not considered a priority by very many or we'd see more people (committers and non-committer contributors) working on it.

-David


On Nov 28, 2012, at 6:02 AM, olivier Heintz <[hidden email]> wrote:

> The mains important point are :
> - This is one way to facilitate Contribution to OFBiz  *AND* Quality
> enhancement
> - Share contribution, even if it's not for all ofbiz user, even if it
> not follow all current bests practices,  can help
> - We need to have a clear definition of what are the Quality criteria
> fro Apache-OFBiz
> - We need to have a clear process for contribution evaluation and status
> and life process
>
> The main comment done by the attendees :
> - It's very important to have a addon repository in Apache-OFBiz
>
> The next steps should be :
> - to write 1,2 or 3 wiki pages for OFBiz choices (writing in a consensus
> way);
> - to give visibility on new help integration
> - to give visibility on functional (or user-interface) test solution
> adopt by OFBiz
> - to start a process on addon manager evaluation
> - to start to give visibility to ofbiz-extra
>
>
>
>
> Le 27/11/2012 11:28, olivier Heintz a écrit :
>> ApacheCon-Eu presentation is now available,
>> http://archive.apachecon.com/eu2012/presentations/07-Wednesday/PR-Community/aceu-2012-ofbizextra-addons_what-constrains-for-each-repository.pdf
>>
>>
>> I propose below a short summary (only the main points) to be able to
>> start community discussion.
>>
>> I will do a second mail for comments about this presentation.
>>
>> Agenda :
>> ======
>> - Why to use OFBiz-extra rather than to include it in Apache-OFBiz?
>> - the ofbizextra-addons Goals
>> - Rules and Constraints by Repository
>> - Process to change
>> - Conclusions
>>
>> Why to use OFBiz-extra rather than to include it in Apache-OFBiz?
>> =========================================
>> - Slim-down process in Apache-OFBiz project
>> - Several technologies for the same function
>> Ex : jasperReport, Birt, …
>> - Licence
>> Ex : GPL
>> - Personal decision versus Apache-OFBiz PMC decision
>> - Work in progress
>> - OOTB solutions for dedicated Business
>>
>> ofbizextra-addons Goals
>> ===============
>> - Facilitate and simplify :
>> * Contribution to OFBiz
>> * Using / Testing added functions
>> * Community and/or OFBiz-committer validation
>> - Increase :
>> * Quality and use of Best Practice
>> * OFBiz functionalities without weighing down kernel
>> * Propose OOTB dedicated solutions for users
>>
>> Rules and Constraints by Repository
>> =======================
>> - 3 repository
>> - ofbiz-extra-addons-dev
>> * This project is open for all contributors who want to create or
>> maintain apache-ofbiz addons.
>> * This project has no quality or best practice control, each contributor
>> should try to do the best he can.
>> * When a user uses an existing addon in this repository, he should
>> assume risks, but but in many cases it will help him.
>> - ofbiz-extra-addons-incubator
>> * This project is open for all Apache-OFBiz addons that should become :
>> + part of ofbiz addons labeled "Quality" repository (ofbizextra-addons),
>> + or part of Apache ofbiz project.
>> * Addons of this project are in a Quality, Best Practice evaluation and
>> enhancement.
>> * There is, at least, one organization / person that is involved to
>> solve bugs or to offer support services for this addon.
>> - ofbiz-extra-addons
>> * Repository of the addons labeled "Quality"
>> * In the future, a similar repository can be created as an Apache-OFBiz
>> sub-project (for addons with Apache2 licence)
>> * There is, at least, one organization / person that is committed to
>> offer support services for this addon.
>> * Addons
>> + Have a complete user help
>> + are included in a Continuous Integration Job :
>> = Installation test
>> = Unit test : Junit
>> = Functional test : Selenium
>>
>> Addon Quality status page
>> (http://code.google.com/a/apache-extras.org/p/ofbiz-extra-addons-incubator/wiki/modelAddonQuality)
>> =================
>> - Update history
>> * contributor, date, version, indicator, description
>> * reviewer, date, version, indicator, description
>> - Base Files
>> * add-on.xml, date, version, status, indicator
>> * maintainer in add-on.xml, date, version, status, indicator
>> * ivy.xml, date, version, status, indicator
>> * addon help (English), date, version, status, indicator
>> * jenkins job, date, version, status, indicator
>> - User Help File
>> * writing, date, version, status, indicator
>> * review and test, date, version, status, indicator
>> - Details
>> * Entity - Field
>> + Entity, FieldName, Label, Field Description, version, indicator
>> * Service
>> + ServiceName, description, Junit, version, indicator
>> * Portlet
>> + PortletName, help, SeedData, parameters, security, selenium, version
>> indicator
>>
>> Conditions to be in Incubator
>> ==================
>> - The minimum is :
>> * add-on.xml and ivy.xml correct
>> * a jenkins job for install testing
>> * addon help wiki page finished
>> * Quality status wiki page created with all boxes
>> * One review for User Help section
>> - Authorized to commit only for
>> * Addon maintainer
>>
>> Condition to return to dev
>> ================
>> - More than 5 consecutive weeks with only failing install test jobs
>> - No answer for user help questions
>> * Answers can be an assistance proposal
>> * and If the user help is not completed
>> - No answer from the maintainer
>> * It's possible to change the addon maintainer if other people do it
>> - New function posted without user help or addon goal change
>> * Quality regression
>> - No support for a new future release-branch
>> * Ofbiz trunk branch support is not mandatory
>>
>> Conditions to become :
>> ==============
>> - Part of Apache-ofbiz
>> * Rules of Apache-OFBiz
>> + The quality status will help the committer to assess the contribution
>> + The evaluation in the incubator can be done by other people than the
>> committer, so as to help the apache-ofbiz committer
>> - In the ofbiz-addons repository labeled “Quality”
>> * All Quality status page items are OK
>> * 5 consecutive weeks with at least one day per week with a successful
>> jenkins job (install+unit+functional)
>> * 2 other addon maintainers ready to become “maintainer deputy” (in two
>> other companies)
>>
>> Condition to “go back” to:
>> ================
>> - Incubator
>> * Quality regression:
>> + New function posted without user help or addon goal change
>> + New service without Junit test
>> + New portlet without selenium test
>> - Dev
>> * More than 5 consecutive weeks with only failing
>> “install-unit-functional test” jobs
>> - Go back or revert commit in ofbizextra-addons and commit new addon in
>> dev or incubator
>>
>> What exist, what is ready
>> ================
>> | addonmanager | ready to use for experienced developer, not for
>> beginner or end user | 1/5 |
>> | adr Addon repository manager | operational, little problem with google
>> code access | 4/5 |
>> | ofbiz-extra-addons-dev | Exists, contains 4 addons for OFBiz
>> PortletWidget branch | 4/5 |
>> | ofbiz-extra-addons-incubator | Exists, work in progress, not yet an
>> addon, the first one will be adm-gui | 2/5 |
>> | ofbiz-extra-addons | not created yet | 0/5 |
>> | user help engine | Current ofbiz help system is usable, new help
>> system is better |
>> | even if there are some functionalities to finish | 3/5 |
>> | addon help | operational with current ofbiz help system, not with the
>> new one | 4/5 |
>> | quality status page per addon | exists but manual update could be too
>> expensive to be usable | 3/5 |
>> | Junit engine in OFBiz | exists and operational in jenkins environment
>> | 5/5 |
>> | selenium engine in OFBiz | exists, but not integrated in ofbiz and
>> still with random errors |
>> | with httpunit-webdriver | 2/5 |
>> | ofbizextra jenkin server | not available yet, but jenkins.neogia.org
>> can be used for the first addons | 1/5 |
>>
>>
>> Conclusions
>> =======
>> - Everything is ready to facilitate contributions
>> * Small ones and larger ones
>> * Technical or/and functional
>> * One function or a Solution
>> - Everything is ready to continue the Apache-OFBiz
>> * Slim-down process
>> + ex: Birt
>> - Everything is ready to start an improvement in quality
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Summary of ApacheCon-Eu conference "Why ofbiz-extra"

Paul Piper
Unfortunately, I would have to second David's opinion. As mentioned in the other mailing-thread, I cannot see any benefit from migrating parts of the source into a google repository. Instead I think that the effects will result in lesser quality product, not higher ones, as discussed here: http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-td4637617.html#a4637828 

So I would argue that it is best to maintain everything in the same trunk as part of the ASF. I would rather like to discuss less enforced guidelines or subproject structures for the apache extras subproject so that those can reach maturity through other means. Don't get me wrong: I do think that a lot of the points & questions you raise are valid, Olivier, and I also agree that we need a structure that would be beneficial to the subproject... but within the same svn trunk and apache ofbiz brand.

That being said: I like the condition-set you gave to identify product maturity. If we can extend the 5week rule to something more suitable for this community (5 weeks is rather short), I believe that those could easily be adapted for a full subproject.
Reply | Threaded
Open this post in threaded view
|

Re: Main priorities to enhance Apache-OFBiz

olivier.heintz Neogia.org
The thread title is confusing for this discussion.

I reformulate my last mail :
Sort from the more important to the less
1) give a process to promote contribution. Contribution should be sent
before quality process review
2) Improve OFBiz Quality, and so accept only contribution with quality
review
2.1) Quality for an ERP should be  for technical and functional at the
same level
2.2) Quality criteria must be clear and well defined
3) be more modular than component level, to be able to measure quality
more easily and precisely
4) slim down ofbiz and put not mandatory function in an option area
5) give a clear process to validate a contribution. Multiple status with
a clear definition for each.
6) give a plan with timelines to classify, on quality criteria, each
existing apache-ofbiz functions
 
7) add more functions // enhance quality of existing functions // move
function from one area to an other (kernel, optional function at hight
quality level, optional function on quality review process, ...)

so, first clarification : ofbiz-extra is a mean and not an end
second clarification : Apache-ofbiz must be for all hight quality ofbiz
piece, kernel or additionals functions.

To be very clear, In My Opinion, the main advantage for ofbiz-extra is ONLY
1) to be able to give a commit authorization for new contributor, to
motivate them to share their current realization
2) to have a unique place for contribution before being evaluate by the
community on quality review process.


If we want a hight level of quality, we should have process to be able
to remove a function from OFBiz-Kernel or "optionals functions",
BECAUSE all code on trunk should be evaluate with the same criteria,
existing from a long time is not a quality criteria. It's not because
something was with a hight quality level that it is always with it.

Last point, maybe quality was not considered as a priority by very many
or we'd see more people (committers and non-committer contributors)
working on it.
But I'm sure it is only related to the development phase where was OFBiz
- increase  number of function -
Now I'm sure many of us to be confident that the quality will enable us
to increase our business.



Le 30/11/2012 09:13, Paul Piper a écrit :

> Unfortunately, I would have to second David's opinion. As mentioned in the
> other mailing-thread, I cannot see any benefit from migrating parts of the
> source into a google repository. Instead I think that the effects will
> result in lesser quality product, not higher ones, as discussed here:
> http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-td4637617.html#a4637828 
>
> So I would argue that it is best to maintain everything in the same trunk as
> part of the ASF. I would rather like to discuss less enforced guidelines or
> subproject structures for the apache extras subproject so that those can
> reach maturity through other means. Don't get me wrong: I do think that a
> lot of the points & questions you raise are valid, Olivier, and I also agree
> that we need a structure that would be beneficial to the subproject... but
> within the same svn trunk and apache ofbiz brand.
>
> That being said: I like the condition-set you gave to identify product
> maturity. If we can extend the 5week rule to something more suitable for
> this community (5 weeks is rather short), I believe that those could easily
> be adapted for a full subproject.
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Summary-of-ApacheCon-Eu-conference-Why-ofbiz-extra-tp4637910p4637949.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: Main priorities to enhance Apache-OFBiz

Jacques Le Roux
Administrator
From: "olivier Heintz" <[hidden email]>
> The thread title is confusing for this discussion.
>
> I reformulate my last mail :
> Sort from the more important to the less
> 1) give a process to promote contribution. Contribution should be sent
> before quality process review

I see roughly 3 types of contribution
1) Bug fixes
2) Improvements of existing features
3) New features

In OFBiz standard contribution process https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
1) are straightforward => create a Jira, attach a patch
2) Don't need to be discussed 1st on the dev ML, except if the improvement is really a big change
3) Should always be discussed 1st on dev ML to avoid disappointments

Those are OFBiz and not Apache conventions, but could still be used as template for Apache OFBiz Extras

> 2) Improve OFBiz Quality, and so accept only contribution with quality
> review

In OFBiz standard contribution processn this is already the case, a committer should always review before committing.
In OFBiz we use the Review Then Commit (RTC) procedure and not the Commit Then Review (CTR) http://www.apache.org/foundation/glossary.html

> 2.1) Quality for an ERP should be  for technical and functional at the
> same level
> 2.2) Quality criteria must be clear and well defined
> 3) be more modular than component level, to be able to measure quality
> more easily and precisely

At this stage I wonder if your discussion (Apache OFBiz Extras? Still not quite clear in the subject ;o)  is not implicilty related to Neogia addons?

> 4) slim down ofbiz and put not mandatory function in an option area

slimdown: https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
Apache OFBiz Extras: http://code.google.com/a/apache-extras.org/hosting/search?q=label%3aOFBiz

> 5) give a clear process to validate a contribution. Multiple status with
> a clear definition for each.
> 6) give a plan with timelines to classify, on quality criteria, each
> existing apache-ofbiz functions

Seems a bit complicated :) Our limited community cannot reasonably sustain too much "paperwork". This has already been expressed by experienced OFBiz committers about this subject. We just need to keep things realistic...
 
> 7) add more functions // enhance quality of existing functions // move
> function from one area to an other (kernel, optional function at hight
> quality level, optional function on quality review process, ...)
>
> so, first clarification : ofbiz-extra is a mean and not an end
> second clarification : Apache-ofbiz must be for all hight quality ofbiz
> piece, kernel or additionals functions.

Totally agreed

> To be very clear, In My Opinion, the main advantage for ofbiz-extra is ONLY
> 1) to be able to give a commit authorization for new contributor, to
> motivate them to share their current realization
> 2) to have a unique place for contribution before being evaluate by the
> community on quality review process.

Still this seems a bit complicated to me. The higher the barriers you put, the less contributions you will get

> If we want a hight level of quality, we should have process to be able
> to remove a function from OFBiz-Kernel or "optionals functions",
> BECAUSE all code on trunk should be evaluate with the same criteria,
> existing from a long time is not a quality criteria. It's not because
> something was with a hight quality level that it is always with it.

Sounds right indeed
 
> Last point, maybe quality was not considered as a priority by very many
> or we'd see more people (committers and non-committer contributors)
> working on it.
> But I'm sure it is only related to the development phase where was OFBiz
> - increase  number of function -

Yes I agree, earlier, and even last, years were more in this mood. Now that OFBiz is "mature" less new features are proposed. But I think also that something else happened/is happening. I'm not yet sure what, but it's like OFBiz has a smell...

> Now I'm sure many of us to be confident that the quality will enable us
> to increase our business.

Yes agreed, we already focus on higher quality than more features. This must no say that no new features should appear...

Jacques

>
>
> Le 30/11/2012 09:13, Paul Piper a écrit :
>> Unfortunately, I would have to second David's opinion. As mentioned in the
>> other mailing-thread, I cannot see any benefit from migrating parts of the
>> source into a google repository. Instead I think that the effects will
>> result in lesser quality product, not higher ones, as discussed here:
>> http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-td4637617.html#a4637828 
>>
>> So I would argue that it is best to maintain everything in the same trunk as
>> part of the ASF. I would rather like to discuss less enforced guidelines or
>> subproject structures for the apache extras subproject so that those can
>> reach maturity through other means. Don't get me wrong: I do think that a
>> lot of the points & questions you raise are valid, Olivier, and I also agree
>> that we need a structure that would be beneficial to the subproject... but
>> within the same svn trunk and apache ofbiz brand.
>>
>> That being said: I like the condition-set you gave to identify product
>> maturity. If we can extend the 5week rule to something more suitable for
>> this community (5 weeks is rather short), I believe that those could easily
>> be adapted for a full subproject.
>>
>>
>>
>> --
>> View this message in context: http://ofbiz.135035.n4.nabble.com/Summary-of-ApacheCon-Eu-conference-Why-ofbiz-extra-tp4637910p4637949.html
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Main priorities to enhance Apache-OFBiz

olivier.heintz Neogia.org
Thank you Jacques for your comment.

I added some comment in-line to clarify what i meant

Le 07/12/2012 09:13, Jacques Le Roux a écrit :

> From: "olivier Heintz" <[hidden email]>
>> The thread title is confusing for this discussion.
>>
>> I reformulate my last mail :
>> Sort from the more important to the less
>> 1) give a process to promote contribution. Contribution should be sent
>> before quality process review
> I see roughly 3 types of contribution
> 1) Bug fixes
> 2) Improvements of existing features
> 3) New features
>
> In OFBiz standard contribution process https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
> 1) are straightforward => create a Jira, attach a patch
> 2) Don't need to be discussed 1st on the dev ML, except if the improvement is really a big change
> 3) Should always be discussed 1st on dev ML to avoid disappointments
>
> Those are OFBiz and not Apache conventions, but could still be used as template for Apache OFBiz Extras
You are right, i did not detailled enough about contribution types
1) Bug fixes, current ofbiz process is clear
2) Improvements of existing features with a good quality level, current
ofbiz process is clear
3) New feature (small or large) not already done, current ofbiz process
is clear
4) New feature (small or large) already developped within contributor
project.
I wanted to insist on the necessity to have a way to contribute.
Obviously, it must be identified as such.
>> 2) Improve OFBiz Quality, and so accept only contribution with quality
>> review
> In OFBiz standard contribution processn this is already the case, a committer should always review before committing.
> In OFBiz we use the Review Then Commit (RTC) procedure and not the Commit Then Review (CTR) http://www.apache.org/foundation/glossary.html
I wanted to point out the fact that all contributions have to respect
quality rules. For instance, every new service (other than auto-entity)
must have a Junit test provided.
>> 2.1) Quality for an ERP should be  for technical and functional at the
>> same level
>> 2.2) Quality criteria must be clear and well defined
>> 3) be more modular than component level, to be able to measure quality
>> more easily and precisely
> At this stage I wonder if your discussion (Apache OFBiz Extras? Still not quite clear in the subject ;o)  is not implicilty related to Neogia addons?
only talking about OFBiz
>> 4) slim down ofbiz and put not mandatory function in an option area
> slimdown: https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
> Apache OFBiz Extras: http://code.google.com/a/apache-extras.org/hosting/search?q=label%3aOFBiz
>
>> 5) give a clear process to validate a contribution. Multiple status with
>> a clear definition for each.
>> 6) give a plan with timelines to classify, on quality criteria, each
>> existing apache-ofbiz functions
> Seems a bit complicated :) Our limited community cannot reasonably sustain too much "paperwork". This has already been expressed by experienced OFBiz committers about this subject. We just need to keep things realistic...
I tried to explain that OFBiz slim-down process have to keep going
beyond the components, and for this purpose we should start by
discussing function by function.
For each function, the quality-level should be estimated. I think that
this kind of contribution could also help the community.

>  
>> 7) add more functions // enhance quality of existing functions // move
>> function from one area to an other (kernel, optional function at hight
>> quality level, optional function on quality review process, ...)
>>
>> so, first clarification : ofbiz-extra is a mean and not an end
>> second clarification : Apache-ofbiz must be for all hight quality ofbiz
>> piece, kernel or additionals functions.
> Totally agreed
>
>> To be very clear, In My Opinion, the main advantage for ofbiz-extra is ONLY
>> 1) to be able to give a commit authorization for new contributor, to
>> motivate them to share their current realization
>> 2) to have a unique place for contribution before being evaluate by the
>> community on quality review process.
> Still this seems a bit complicated to me. The higher the barriers you put, the less contributions you will get
>
>> If we want a hight level of quality, we should have process to be able
>> to remove a function from OFBiz-Kernel or "optionals functions",
>> BECAUSE all code on trunk should be evaluate with the same criteria,
>> existing from a long time is not a quality criteria. It's not because
>> something was with a hight quality level that it is always with it.
> Sounds right indeed
>  
>> Last point, maybe quality was not considered as a priority by very many
>> or we'd see more people (committers and non-committer contributors)
>> working on it.
>> But I'm sure it is only related to the development phase where was OFBiz
>> - increase  number of function -
> Yes I agree, earlier, and even last, years were more in this mood. Now that OFBiz is "mature" less new features are proposed. But I think also that something else happened/is happening. I'm not yet sure what, but it's like OFBiz has a smell...
>
>> Now I'm sure many of us to be confident that the quality will enable us
>> to increase our business.
> Yes agreed, we already focus on higher quality than more features. This must no say that no new features should appear...
+1 ;-)

> Jacques
>
>> Le 30/11/2012 09:13, Paul Piper a écrit :
>>> Unfortunately, I would have to second David's opinion. As mentioned in the
>>> other mailing-thread, I cannot see any benefit from migrating parts of the
>>> source into a google repository. Instead I think that the effects will
>>> result in lesser quality product, not higher ones, as discussed here:
>>> http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-td4637617.html#a4637828 
>>>
>>> So I would argue that it is best to maintain everything in the same trunk as
>>> part of the ASF. I would rather like to discuss less enforced guidelines or
>>> subproject structures for the apache extras subproject so that those can
>>> reach maturity through other means. Don't get me wrong: I do think that a
>>> lot of the points & questions you raise are valid, Olivier, and I also agree
>>> that we need a structure that would be beneficial to the subproject... but
>>> within the same svn trunk and apache ofbiz brand.
>>>
>>> That being said: I like the condition-set you gave to identify product
>>> maturity. If we can extend the 5week rule to something more suitable for
>>> this community (5 weeks is rather short), I believe that those could easily
>>> be adapted for a full subproject.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://ofbiz.135035.n4.nabble.com/Summary-of-ApacheCon-Eu-conference-Why-ofbiz-extra-tp4637910p4637949.html
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Main priorities to enhance Apache-OFBiz

Jacques Le Roux
Administrator
From: "olivier Heintz" <[hidden email]>

> Thank you Jacques for your comment.
>
> I added some comment in-line to clarify what i meant
>
> Le 07/12/2012 09:13, Jacques Le Roux a écrit :
>> From: "olivier Heintz" <[hidden email]>
>>> The thread title is confusing for this discussion.
>>>
>>> I reformulate my last mail :
>>> Sort from the more important to the less
>>> 1) give a process to promote contribution. Contribution should be sent
>>> before quality process review
>> I see roughly 3 types of contribution
>> 1) Bug fixes
>> 2) Improvements of existing features
>> 3) New features
>>
>> In OFBiz standard contribution process https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
>> 1) are straightforward => create a Jira, attach a patch
>> 2) Don't need to be discussed 1st on the dev ML, except if the improvement is really a big change
>> 3) Should always be discussed 1st on dev ML to avoid disappointments
>>
>> Those are OFBiz and not Apache conventions, but could still be used as template for Apache OFBiz Extras
> You are right, i did not detailled enough about contribution types
> 1) Bug fixes, current ofbiz process is clear
> 2) Improvements of existing features with a good quality level, current
> ofbiz process is clear
> 3) New feature (small or large) not already done, current ofbiz process
> is clear
> 4) New feature (small or large) already developped within contributor
> project.
> I wanted to insist on the necessity to have a way to contribute.
> Obviously, it must be identified as such.

I don't see the difference between 3 and 4. From a committer POV it's the same. So I must be missing something. You mean in the only context of Apache OFBiz Extras?

>>> 2) Improve OFBiz Quality, and so accept only contribution with quality
>>> review
>> In OFBiz standard contribution processn this is already the case, a committer should always review before committing.
>> In OFBiz we use the Review Then Commit (RTC) procedure and not the Commit Then Review (CTR) http://www.apache.org/foundation/glossary.html
> I wanted to point out the fact that all contributions have to respect
> quality rules. For instance, every new service (other than auto-entity)
> must have a Junit test provided.

That would be wonderful, but so far we never reached this stage ("must have").
Also I don't think the OFBiz project wants to force people to provide Junit test for each feature.
And finally there are already a lot of contributions waiting. The contributors should 1st understand that not only committers can review and test. When a contribution is reviewed and/or tested by another contributor than the author the committers work is much reduced and the quality is improved. We are still in the slimdown phase effort. And this means that we (committers) favour bug fixes.

>>> 2.1) Quality for an ERP should be  for technical and functional at the
>>> same level
>>> 2.2) Quality criteria must be clear and well defined
>>> 3) be more modular than component level, to be able to measure quality
>>> more easily and precisely
>> At this stage I wonder if your discussion (Apache OFBiz Extras? Still not quite clear in the subject ;o)  is not implicilty related to Neogia addons?
> only talking about OFBiz

I then wonder how (resources) you envision to reach such a challenge... We have already some difficulties to cope with the curren contributions. How would you decide on quality? To be frank, this is freightening to me. I foresee administrative work in your intention, but I must be wrong, right? So far we decided on quality by peer review and lazy consensus, what would you want to add?

>>> 4) slim down ofbiz and put not mandatory function in an option area
>> slimdown: https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
>> Apache OFBiz Extras: http://code.google.com/a/apache-extras.org/hosting/search?q=label%3aOFBiz
>>
>>> 5) give a clear process to validate a contribution. Multiple status with
>>> a clear definition for each.

Don't you fear a too much admistrative work?

>>> 6) give a plan with timelines to classify, on quality criteria, each
>>> existing apache-ofbiz functions
>> Seems a bit complicated :) Our limited community cannot reasonably sustain too much "paperwork". This has already been expressed by experienced OFBiz committers about this subject. We just need to keep things realistic...
> I tried to explain that OFBiz slim-down process have to keep going
> beyond the components, and for this purpose we should start by
> discussing function by function.
> For each function, the quality-level should be estimated. I think that
> this kind of contribution could also help the community.

How and by who the "quality-level should be estimated" is the basic question. Not even sure the OFBiz team agree about that, sounds like a tremendous work for "existing apache-ofbiz functions"

>>  
>>> 7) add more functions // enhance quality of existing functions // move
>>> function from one area to an other (kernel, optional function at hight
>>> quality level, optional function on quality review process, ...)
>>>
>>> so, first clarification : ofbiz-extra is a mean and not an end
>>> second clarification : Apache-ofbiz must be for all hight quality ofbiz
>>> piece, kernel or additionals functions.
>> Totally agreed
>>
>>> To be very clear, In My Opinion, the main advantage for ofbiz-extra is ONLY
>>> 1) to be able to give a commit authorization for new contributor, to
>>> motivate them to share their current realization

Actually this is not related to commit authorization  at all. It's just a place to share things between contributor (which include committers). We can already do the same things by other means. It's just a bit more official and (hopefully) better organised.

>>> 2) to have a unique place for contribution before being evaluate by the
>>> community on quality review process.

Yes that's it. I see you much insist on quality. Do you mean that we should use a tools like Selenium or (better IMO) webdriver? Should we dedicate specific human resources for OFBiz quality assurance? This would be a good thing to discuss at least. Nowadays all serious projects are guaranteed by a quality process with dedicated person/s. Just stumbled upon http://wiki.openoffice.org/wiki/Quality_Assurance. But it seems to me that infra  does not provide tools and especially enough resources for that. So would this be done externally, something to discuss... Well, when I really think about it, as I said it's freightening :D

>> Still this seems a bit complicated to me. The higher the barriers you put, the less contributions you will get
>>
>>> If we want a hight level of quality, we should have process to be able
>>> to remove a function from OFBiz-Kernel or "optionals functions",
>>> BECAUSE all code on trunk should be evaluate with the same criteria,
>>> existing from a long time is not a quality criteria. It's not because
>>> something was with a hight quality level that it is always with it.
>> Sounds right indeed
>>  
>>> Last point, maybe quality was not considered as a priority by very many
>>> or we'd see more people (committers and non-committer contributors)
>>> working on it.
>>> But I'm sure it is only related to the development phase where was OFBiz
>>> - increase  number of function -
>> Yes I agree, earlier, and even last, years were more in this mood. Now that OFBiz is "mature" less new features are proposed. But I think also that something else happened/is happening. I'm not yet sure what, but it's like OFBiz has a smell...

Let me clarify "OFBiz has a smell..." I refer to Frank Zappa: "Jazz isn't dead. It just smells funny." I say that because I see less activity and I wonder why. Of course David's departure is a part of the cause, but it does not explain all.

>>> Now I'm sure many of us to be confident that the quality will enable us
>>> to increase our business.
>> Yes agreed, we already focus on higher quality than more features. This must no say that no new features should appear...
> +1 ;-)

Now it seems that Jacopo proposed something new recently (to address Paul's and others concern). I can't find it, but IIRW it was about extras in repo but not in releases, an intermediate stage. This sounds like an adequate proposition to me (not related to quality)

Jacques

>> Jacques
>>
>>> Le 30/11/2012 09:13, Paul Piper a écrit :
>>>> Unfortunately, I would have to second David's opinion. As mentioned in the
>>>> other mailing-thread, I cannot see any benefit from migrating parts of the
>>>> source into a google repository. Instead I think that the effects will
>>>> result in lesser quality product, not higher ones, as discussed here:
>>>> http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-td4637617.html#a4637828 
>>>>
>>>> So I would argue that it is best to maintain everything in the same trunk as
>>>> part of the ASF. I would rather like to discuss less enforced guidelines or
>>>> subproject structures for the apache extras subproject so that those can
>>>> reach maturity through other means. Don't get me wrong: I do think that a
>>>> lot of the points & questions you raise are valid, Olivier, and I also agree
>>>> that we need a structure that would be beneficial to the subproject... but
>>>> within the same svn trunk and apache ofbiz brand.
>>>>
>>>> That being said: I like the condition-set you gave to identify product
>>>> maturity. If we can extend the 5week rule to something more suitable for
>>>> this community (5 weeks is rather short), I believe that those could easily
>>>> be adapted for a full subproject.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://ofbiz.135035.n4.nabble.com/Summary-of-ApacheCon-Eu-conference-Why-ofbiz-extra-tp4637910p4637949.html
>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>
>