[PROPOSAL] from specialpurpose to extras

[Jacopo Cappellato-4]

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

[Adrian Crum-3]

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
>

[Jacopo Cappellato-4]

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
>>
>
>
>

[Adrian Crum-3]

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
>>>
>>
>>

[Jacopo Cappellato-4]

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
>>>>
>>>
>>>
>
>
>

[Jacques Le Roux]

I have nothing against these ideas. It seems to me though that some applications currently in specialpurpose are more used and/or
have a larger scope than some others.

Roughly said I see 2 kinds of components there:
"1st class citizens" would be
assetmaint
ecommerce
example*
pos
maybe myportal?
projectmgr
scrum
and maybe webpos?

"2nd class citizens" would be all the rest but workflow which should be moved to Attic ASAP (I will do soon
https://issues.apache.org/jira/browse/OFBIZ-4900)
They are more like addons that actually less people use.

I still wonder if moving "1st class citizens" out of the repo will be a good thing for those component... I bet they will have less
audience...

So I'm inclined to move "1st class citizens" in applications with ecommerce, and let the rest go to Extra or even Attic (one of ebay
and ebaystore for instance, with dependencies resolved 1st)

Anyway these are long terms plans and I think things will change in the meantime...

Jacques

From: "Jacopo Cappellato" <[hidden email]>

> 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
>>>>>
>>>>
>>>>
>>
>>
>>
>
>

[Jacques Le Roux]

Ha, I forgot about the release aspect of the discussion. I agree, to have less burden on committers shoulders when releasing, we
could put the specialpurpose folder out of releases branches. But then I wonder how they will be maintained in future. This is what
is worrying me a bit: releases will not receive specialpurpose folder bug fixes backport then. They will really then not be "1st
class citizens", not sure it's a good signal for current even future users and of these components...

Jacques

From: "Jacques Le Roux" <[hidden email]>

>I have nothing against these ideas. It seems to me though that some applications currently in specialpurpose are more used and/or
>have a larger scope than some others.
>
> Roughly said I see 2 kinds of components there:
> "1st class citizens" would be
> assetmaint
> ecommerce
> example*
> pos
> maybe myportal?
> projectmgr
> scrum
> and maybe webpos?
>
> "2nd class citizens" would be all the rest but workflow which should be moved to Attic ASAP (I will do soon
> https://issues.apache.org/jira/browse/OFBIZ-4900)
> They are more like addons that actually less people use.
>
> I still wonder if moving "1st class citizens" out of the repo will be a good thing for those component... I bet they will have
> less audience...
>
> So I'm inclined to move "1st class citizens" in applications with ecommerce, and let the rest go to Extra or even Attic (one of
> ebay and ebaystore for instance, with dependencies resolved 1st)
>
> Anyway these are long terms plans and I think things will change in the meantime...
>
> Jacques
>
> From: "Jacopo Cappellato" <[hidden email]>
>> 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
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>

[Jacopo Cappellato-4]

On Jul 9, 2012, at 10:28 PM, Jacques Le Roux wrote:

> Ha, I forgot about the release aspect of the discussion. I agree, to have less burden on committers shoulders when releasing, we could put the specialpurpose folder out of releases branches. But then I wonder how they will be maintained in future. This is what is worrying me a bit: releases will not receive specialpurpose folder bug fixes backport then.

The idea is to not include the specialpurpose folder from future releases: 13.04, 14.04 etc...

Jacopo

[Jacopo Cappellato-4]

It is difficult to groups components in this way because it is based on your personal experience (mine would be completely different, for example).
The fact that they are not part of the future "OFBiz releases" doesn't mean that they will not be used, in fact they can be downloaded separately.

Jacopo

On Jul 9, 2012, at 10:20 PM, Jacques Le Roux wrote:

> I have nothing against these ideas. It seems to me though that some applications currently in specialpurpose are more used and/or have a larger scope than some others.
>
> Roughly said I see 2 kinds of components there:
> "1st class citizens" would be
> assetmaint
> ecommerce
> example*
> pos
> maybe myportal?
> projectmgr
> scrum
> and maybe webpos?
>
> "2nd class citizens" would be all the rest but workflow which should be moved to Attic ASAP (I will do soon https://issues.apache.org/jira/browse/OFBIZ-4900)
> They are more like addons that actually less people use.
>
> I still wonder if moving "1st class citizens" out of the repo will be a good thing for those component... I bet they will have less audience...
>
> So I'm inclined to move "1st class citizens" in applications with ecommerce, and let the rest go to Extra or even Attic (one of ebay and ebaystore for instance, with dependencies resolved 1st)
>
> Anyway these are long terms plans and I think things will change in the meantime...
>
> Jacques
>
> From: "Jacopo Cappellato" <[hidden email]>
>> 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
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>

[Pierre Smits]

2012/7/10 Jacopo Cappellato <[hidden email]>

>
> The idea is to not include the specialpurpose folder from future releases:
> 13.04, 14.04 etc...
>
>
> -1

[Olivier.heintz]

All you proposed sound good to me.

Since first discussion about "Lose Weight Program for OFBiz" we (the
company I am working for) have continue to work on addon definition,
rule, goal.
In my current plan, I am 3 week late, but this week (or next one ) I
should create in apache-extra some project :
- addon manager
- addon repository
- ofbiz-extra
- ofbiz-extra-proposed
- ofbiz-extra-dev

for the first addons, I will try to use existing Jira (like theme
proposed, or help system, ...)
The main idea is to be ready (tools, project on apache-extra and time)  
to help you to each step.

About release, I agree with Jacopo, OFBiz release should be for ofbiz kernel
and release for ofbiz-extras should exist but it is a other process, not
necessary same people for management for example.

Le 09/07/2012 15:09, Jacopo Cappellato a écrit :

> 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
>>>>>
>>>>
>>
>>
>

[BJ Freeman]

So the concerns, as I read the thread, is review of code for release
needs to be minimized.
Instead of shrinking the SVN Image, I present the following.
1) expand the tests to verify each component/folder. This would reduce
release review.
2) expand the ant script or create seperate one for Distribution, where
folders are copied to a new root folder, and appropriate changes to the
files are done. this would save a lot of documentation. Short of like
the hot-deploy new component script. Each component/folder would have a
script to handle it specific requirement.

If every committer took what they are familiar with and covered #1 and
#2 this should not be any more effort than changing the schema of the SVN

To me this would make Ofbiz something a not so technical person deploy a
OFbiz image specific to their concerns.

For those that hold this was a project to create cash flow, I put to you
that there is plenty consulting opportunities in doing the business
setup, that is more lucrative than coding.

At least that is what I have found with my customers.



Jacopo Cappellato sent the following on 7/9/2012 3:21 AM:

> 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
>
>

[Jacques Le Roux]

Looks promising Olivier,

Looking forward

Jacques

From: "Olivier Heintz" <[hidden email]>

> All you proposed sound good to me.
>
> Since first discussion about "Lose Weight Program for OFBiz" we (the company I am working for) have continue to work on addon
> definition, rule, goal.
> In my current plan, I am 3 week late, but this week (or next one ) I should create in apache-extra some project :
> - addon manager
> - addon repository
> - ofbiz-extra
> - ofbiz-extra-proposed
> - ofbiz-extra-dev
>
> for the first addons, I will try to use existing Jira (like theme proposed, or help system, ...)
> The main idea is to be ready (tools, project on apache-extra and time)  to help you to each step.
>
> About release, I agree with Jacopo, OFBiz release should be for ofbiz kernel
> and release for ofbiz-extras should exist but it is a other process, not necessary same people for management for example.
>
> Le 09/07/2012 15:09, Jacopo Cappellato a écrit :
>> 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
>>>>>>
>>>>>
>>>
>>>
>>
>
>
>