Adrian, all you proposed sounds good to me, I like it. What about the idea of not including specialpurpose in the releases? I think it is important because it simplifies the task of reviewing the code that we officially publish when we do a release; releasing separately will help to focus on a smaller amount of code every time we do a release.
Jacopo On Jul 9, 2012, at 12:50 PM, Adrian Crum wrote: > I like the general direction, but I think the steps are overly complicated. I > would prefer to keep the specialpurpose folder name, and keep its components > in the build scripts and test runs. This is important because higher level > component tests can reveal problems in the core logic (those tests were > invaluable during the Mini-language overhaul). > > So, let's move stuff into specialpurpose, then move bits of specialpurpose > out of the project. When the specialpurpose folder is empty, we can remove it. > > The eCommerce component could be moved to the applications folder. > > I would be interested in spinning off the Asset Maintenance component to a > separate project. Maybe we could use that as a test run of the "extras" > concept. > > -Adrian > > > On 7/9/2012 11:21 AM, Jacopo Cappellato wrote: >> A few months ago we discussed about moving out of OFBiz some components from >> framework and specialpurpose and introduce the concept of "OFBiz Extras" >> projects, managed out of the ASF infrastructure. >> I still think it is a good way to go, especially because it will help to >> grow an ecosystem of projects not necessarily licensed under the same >> license. >> However I understand that this will take time to adjust and a lot of work to >> setup communities etc... this is the main reason I have prepared this >> proposal for an intermediate step: instead of moving out the components we >> can move them to the "specialpurpose" folder, rename it into "extras" and >> exclude the folder from the ootb build/deployment and from releases. >> >> Some more details: >> * the extras folder will not be included in build scripts, test runs, >> deployments; in order to build/run/test an extras component, it will have to >> be dropped into the hot-deploy folder >> * extras components are not deployed on our demo instances, or included in >> automated builds; no dependency on them (links, documentation etc...) will >> exist in the OFBiz codebase >> * some of the components in the extras folder could be experimental; each >> component should contain a README file with all the information required to >> deploy it successfully >> * a separate LICENSE file will be maintained in the extras folder >> * extras folder will not be part of the future OFBiz releases; we will >> instead release all the extras components in one package as "Apache OFBiz >> Extras" let's say every year >> * we may consider to move back ecommerce from specialpurpose/extras to >> applications, at least the core ecommerce features >> >> Considering that the components are either experimental or very specific, it >> will be easier to get commit rights for one or more of the "extras" >> components; new committers will be formally "OFBiz committers" (i.e. in >> theory they will have right to change all code in svn, including ofbiz code) >> but they will be asked to limit their field of action to the components they >> have been voted for; it will be based on trust rather than commit rights; a >> formal vote will be still required to authorize the committer to other >> components; the fact that a committer will still have the ability to change >> all code could be an advantage if we allow them to commit code under the >> explicit permission of another senior committer on specific case; for >> example a senior committer could say "I have committed r123456 and this >> should be backported to 12.04 and 11.04 but I don't have time; is there a >> committer available to help to backport and test the feature?" >> This strategy, to have committers that are asked to not commit out of >> specific components, or areas (we could, for example, have a committer >> allowed to only work on ui labels), could even be considered for old >> committers (whose commit history shows lack of quality)... but this is >> probably topic for another day. >> >> In short, this approach should help in a few areas: smaller core code base, >> greater community of specialized committers, less load on existing >> committers. >> >> What do you think? >> >> Jacopo >> > > >
