Hi Ron, As soon as the improvement work (and that is what it should be regarded as) is somewhere in trunk or a release branch (not dev branch or patch), it is part of the OFBiz works (the total of code and documentation, etc). Even preliminary work in dev branches and drafts that doesn't make it into trunk and/or a release branch is part of the works of the OFBiz project. Anything included in a release (how incomplete/unfinished someone may regard it) is a specific subset of the total works.
As for your second part of your statement quality of a release has been focused in the past more on code than on the other (and equally important) elements. Yes, the PMC should advocate both sides and should work to get the various contributors in as committers so that we would not get to situations where code is excellent, but the rest is not (or vice-versa) and potential adopters can not implement (business wise) without a lot of effort spent on the other elements. In any case, issues created in JIRA will expose deficiencies regarding completeness of new features, add ons, and other potential improvements. A little collaboration has great effect. And pointing fingers towards the other contributor (which we all are) isn't exactly collaborating or building consensus. Best 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 Tue, Mar 10, 2015 at 7:27 PM, Ron Wheeler <rwhee...@artifact-software.com > wrote: > From an end-user point of view, I would like to see the PMC start with the > mindset of > "This feature/function/component is part of the "OFBiz product" and we > will not release a new branch/version that does not include a fully > functional and tested version of this component/feature." > as the criteria for accepting a new feature. > > Anything that can not get this warranty from the PMC should be a separate > sub-project with any warranty provided by the supporters/promoters of the > particular feature/function/component. > > This would clarify what people can expect and would reduce the confusion > around releases where components shift in and out on a whim. > > This means that people who want a new release have to understand that > there is a set of functionality that may not affect them personally but > still has to be integrated into a new release for the sake of the > reputation of the product. > If you add something that breaks something, you need to fix the thing that > got broken or had its functionality impacted. > > This might slow down the implementation of new features into the core > OFBiz but it would be somewhat easier to get a new component into > incubation as a feature with a limited warranty since the PMC would not > have to consider the long-term maintenance until the component had the > following to be considered as part of the "core" application. If it fails > to work or get used, there is no impact on the core. If it does not get > updated to the latest release, it does reflect badly on the core and does > not hold up the core's progress. > > Ron > > > > On 10/03/2015 2:04 PM, Jacopo Cappellato wrote: > >> Hi Pierre, >> >> please see inline: >> >> On Feb 27, 2015, at 12:30 PM, Pierre Smits <pierre.sm...@gmail.com> >> wrote: >> >> Jacopo, All, >>> >>> I am a proponent of any kind of OFBiz integration solution that will >>> enhance the feature set and drives the adoption. It is good to see that >>> people are willing to put the effort in, as we see (and have seen) with >>> components (like BIRT, PoS) and other attempts (Asterisk integration, >>> Jackrabbit, etc) and solutions (Magnolia/CATO, BigFish). >>> >>> However, I remember a discussion thread not long ago where strong >>> opinions >>> were voiced about not having more under the umbrella of the Apache OFBiz >>> project. >>> >> In my opinion this is a separate (but interesting/important) topic that >> should not interfere with this proposal; that discussion could go on for >> months but the current situation is that in the OFBiz trunk we have >> additional (specialpurpose) components and until we have them then we can >> also consider the adoption of new ones (if valuable); if and when we will >> decide to move all the components to another place (another trunk or an >> external repository etc...) then we will move all (or most) of them >> including new ones. >> >> It seems to me that we should discuss strategy, process and risks first, >>> before we discuss integration of anything into the project. Otherwise we >>> will be having the same discussion over and over with each integration >>> idea >>> that pops up. >>> >> We will never come up with a general rule for inclusion/exclusion and we >> will have to take a decision on a case by case basis considering different >> factors including: code quality, interest by the community, committers >> available to help, etc... >> The important topic, in my opinion, for this thread is figuring out if >> such a component may be interesting to end user companies (but for them we >> will have to look into Magento forums) or to service providers with >> customers in the OFBiz and Magento space. >> >> Regards, >> >> Jacopo >> >> Best 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, Feb 27, 2015 at 9:17 AM, Jacopo Cappellato < >>> jacopo.cappell...@hotwaxsystems.com> wrote: >>> >>> Hi all, >>>> >>>> in the last year, the research and development lab of HotWax Systems has >>>> implemented a series of components and tools for OFBiz. >>>> Some of them are ready-to-be-used applications and, in my opinion, would >>>> be a good fit for OFBiz. >>>> >>>> After discussing the topic internally, we believe that the community >>>> could >>>> benefit from them and at the same time help to further improve them. >>>> >>>> Accordingly, I would like to start by exploring with you the opportunity >>>> to include in OFBiz our integration with Magento eCommerce platform. >>>> >>>> Magento eCommerce (http://magento.com/products/overview) is a popular >>>> solution for merchants; it is an open source product (but the company is >>>> owned by eBay). >>>> In terms of features it competes with the OFBiz ecommerce component, but >>>> it is easier to setup and with a shorter go to market. >>>> For these reasons it is a good fit for small-medium merchants that need >>>> an >>>> ecommerce store with no backend capabilities and it has a very large >>>> users >>>> base. >>>> >>>> We realized that there could be a rather large group of merchants, >>>> already >>>> using Magento for online sales, that may be interested in integrating it >>>> with a powerful ERP system for the backend tasks (order fulfillment, >>>> accounting etc...). >>>> >>>> The integration component we have implemented has a nice user interface >>>> to >>>> import categories, products, orders from Magento eCommerce and then >>>> synch >>>> held/cancelled orders; there are screens to manage shipment options and >>>> product store settings. >>>> >>>> You can find some screenshot here: >>>> http://people.apache.org/~jacopoc/magento-integration-2.png >>>> http://people.apache.org/~jacopoc/magento-integration-3.png >>>> http://people.apache.org/~jacopoc/magento-integration-4.png >>>> http://people.apache.org/~jacopoc/magento-integration-5.png >>>> >>>> Arun Patidar led the effort and is happy to provide additional details >>>> so >>>> please feel free to ask any questions. >>>> >>>> In my opinion this product could be integrated as a specialpurpose >>>> component, but I am open to suggestions. >>>> >>>> What do you think? >>>> >>>> Jacopo >>>> >>> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
