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
