Re: Main priorities to enhance Apache-OFBiz
From: olivier Heintz olivier.hei...@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 olivier.hei...@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 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
Re: Main priorities to enhance Apache-OFBiz
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 olivier.hei...@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 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
Re: Main priorities to enhance Apache-OFBiz
From: olivier Heintz olivier.hei...@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 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,
Re: Main priorities to enhance Apache-OFBiz
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.
