Yes, this could be the easiest way to implement it. And if and when we will release the "specialpurpose" applications we could simply create a tag (if we do not plan to backport fixes for "specialpurpose" releases) or we could create a release branch specific for "specialpurpose" (if we do not want to backport fixes for "specialpurpose" releases).
Jacopo On Jul 9, 2012, at 2:59 PM, Adrian Crum wrote: > So, we would remove the specialpurpose folder from the release branch? That > sounds fine to me. > > -Adrian > > On 7/9/2012 1:55 PM, Jacopo Cappellato wrote: >> 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 >>>> >>> >>> > > >
