You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@sandglass-software.com> on 2014/11/28 17:20:36 UTC
Move The Asset Maintenance Component To A Separate Project (was:
Suggest branch rather than release strategy?)
As has been discussed in this thread, we can spin off special purpose
components to their own projects - where they can form their own
communities and support structure.
I am willing to use the Asset Maintenance component as a trial run. Here
are some of my initial thoughts, comments are welcome:
1. Check with the ASF legal department before doing anything.
2. Create a project on a popular hosting site (like SourceForge, but it
could be anywhere).
3. Set up initial committers.
4. Notify the OFBiz mailing lists about the new project.
5. Drop the Asset Maintenance component from the ASF repo.
The component would maintain the ASL 2 license. Support for various
versions of OFBiz will be decided by the Asset Maintenance community.
If the spin-off is a success, then all is good. If it fails, then the
Asset Maintenance component is added back to the ASF repo.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 11/28/2014 4:01 PM, Ron Wheeler wrote:
> The components not supported as part of the core and framework would not
> leave Apache.
> They become separate sub-projects under OFBiz so that they stay in the
> community but are released and supported separately so that there is
> more transparency about their state.
> The release of new core and framework versions gets easier.
>
> The implied warranties get clearer and the sub-communities supporting
> each of the non-core components are :
> -easier to identify
> - free to set their own roadmaps based on the needs and the resources
> - easier to join since you only need to learn a small set of code in
> order to contribute
> - do not affect the core and framework code, roadmap or release plans
> except when they request extensions to the core or framework through
> JIRA issues.
>
> The core and framework team will not have to worry about the side
> components unless they belong to the sub-project and can release with a
> full warranty.
>
> Ron
>
>
> On 28/11/2014 10:30 AM, gil portenseigne wrote:
>> First I might be a bit confuse in this email, sorry for that, quite
>> ideas came up while writing it, some organization missing.
>>
>> Le 28/11/2014 14:31, Ron Wheeler a écrit :
>>> What is the downside if the non-core components are released on their
>>> own with a clear set of documentation that describes the state of the
>>> component?
>> I guess there is none at first glance, it's quite the same idea :
>> - A big release with core components active, and non-core component
>> unactive (with included documentations)
>> A monolythique one, all-included...
>>
>> - A Core release, first with then optional non-core component releases
>> with their own documentations
>> A core with packages. Less heavy but more actions... not a problem
>>
>> The things that make me wonder, and that's we try to achieve for
>> several years with an extension management tool, are all the deviance
>> possible without the control of such an Apache project.
>>
>> It is Out of Apache ! The component community can build their own
>> component at the speed they need (often dependant on a personal
>> project), without the quality control. It's good for this side
>> community, we are already doing that in our way. But can lead to a
>> branch component, which can't be contributed anymore to OFBiz if
>> needed (for any reasons I guess).
>>
>> Why not stick with Apache OFBiz in contributing more, into
>> desactivated non-core component using the side community advancement,
>> and managing to level up these non-core quality too make them stable
>> and reliable into Apache OFBiz.
>>
>> Specifics devs that can't be contributed into OFBiz, will remain as
>> extension into the side community.
>>
>> If side community meets some deviance in his evolution, not following
>> Apache OFBiz way, it must not have consequences like removing these
>> non-core component from trunk or branches.
>>
>> That's why i like the idea to have in Apache OFBiz, release with
>> unactive components (which can always be used and follow the Ofbiz
>> way), and then everyone have the opportunity to offer other community
>> components to replace unactive one, or to add to the core.
>>
>> Then some questions remains :
>> - How can user be informed of such side communities from the OFBiz
>> official site ? Is that possible ?
>> - We tried to introduce a new tool to manage extension (which could be
>> a solution for the first question, becoming a tool of indexation ) to
>> serve this kind of purpose, but their wasn't much reactions to it. Cf
>> : http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
>>
>>
>> Gil
>>
>>>
>>> My feeling is that it is better to release a clean core and framework
>>> where ALL component are "warranteed" by the team to be tested and
>>> supported.
>>> Components that are not part of the core would be released on their
>>> own with the warranty and support specified on an individual basis.
>>>
>>> At least the user community would know where it stands if it depends
>>> a non-core component to run their business.
>>>
>>> I think this is preferable than releasing a big conglomeration of
>>> working and non-working software that the user has to sort through to
>>> figure out if they can make a usable OFBiz.
>>>
>>> It also simplifies the release process for the core and framework.
>>>
>>> Ron
>>>
>>> On 28/11/2014 7:18 AM, gil portenseigne wrote:
>>>> Hello all !
>>>>
>>>> I followed the discussion, a bit late :
>>>>
>>>> Le 28/11/2014 11:24, Jacques Le Roux a écrit :
>>>>> Afterthought: we agreed about having the same setting in both the
>>>>> releases branches and the trunk. So if we disable a component in
>>>>> the releases branches it will be also in the trunk.
>>>>> Then, even we enable tests, we will not be aware of UI related
>>>>> issues and globally all those which are no covered by tests. Apart
>>>>> if an users enable the component and report issues.
>>>>>
>>>>> This might be a compromise, but we need our users to be aware of.
>>>>> So they will need to be warned in the download page IMO.
>>>>>
>>>> I think it's a good compromise, warning is needed to ensure that
>>>> user is aware or possible disfunctionment within these components.
>>>> No tricks needed anymore to import components from trunk. Good
>>>> enough for me.
>>>>
>>>> My opinion is that OOTB functionnalities are usable but rarely
>>>> sufficient for End-User, advanced skills are needed in each project
>>>> to make OFBiz fit the needs. So i guess there is no harm to let
>>>> inactive (uncomplete or so) component at disposal for user who might
>>>> need them.
>>>>> Also if you remember this thread started with my idea of creating a
>>>>> wiki page to explain to our users the alternative strategy of using
>>>>> release branches rather than released packages.
>>>>> I'd like to have a direct link to this wiki page from the download
>>>>> page. This link name could be simply "alternative strategy". What
>>>>> do you think?
>>>> Using the same method, i like the idea.
>>>>
>>>> Gil
>>>>>
>>>>> I will stop this thread here and will create a new thread to
>>>>> discuss the modality of putting back the specialpurpose components
>>>>> in the R13.07 branch.
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 27/11/2014 23:38, Jacques Le Roux a écrit :
>>>>>> That sounds like a good enough solution to me
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 27/11/2014 19:41, Jacopo Cappellato a écrit :
>>>>>>> This is a good point. We could find a way to programmatically
>>>>>>> enable/disable the components just for the test run:
>>>>>>>
>>>>>>> ./ant -Denable-all=true clean-all load-demo run-tests
>>>>>>>
>>>>>>> but this is just an idea; we could figure out the best way to go.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>
>>>>>>> On Nov 27, 2014, at 7:14 PM, Adrian Crum
>>>>>>> <ad...@sandglass-software.com> wrote:
>>>>>>>
>>>>>>>> Be aware that disabling a component does two things:
>>>>>>>>
>>>>>>>> 1. Speeds up unit tests because the disabled component is
>>>>>>>> excluded from them.
>>>>>>>> 2. Increases the chance of regressions because the disabled
>>>>>>>> component is not being tested.
>>>>>>>>
>>>>>>>> Adrian Crum
>>>>>>>> Sandglass Software
>>>>>>>> www.sandglass-software.com
>>>>>>>>
>>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
>>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux
>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>
>>>>>>>>>> Yes, so we need to define which are those components. So 3
>>>>>>>>>> points, which should be discussed separately it seems, not
>>>>>>>>>> sure of the order yet but probably this one
>>>>>>>>>> 1) Components to move to Attic. They will be freezed but still
>>>>>>>>>> available in this state in Attic (in other words slowly dying)
>>>>>>>>>> 2) Components to disable. They will be maintained, but OOTB
>>>>>>>>>> will not interfere with other components (applications or
>>>>>>>>>> other specialpurpose)
>>>>>>>>>> 3) Components to keep enabled. They must be maintained and
>>>>>>>>>> have no interactions with other components
>>>>>>>>> Components enabled and disabled must be maintained in the same
>>>>>>>>> way: it is not that a group is more important than the other.
>>>>>>>>> Also, disabling a component doesn't mean that it will not go in
>>>>>>>>> a release: we could have disabled components in releases and
>>>>>>>>> enabled components excluded from a release or vice versa.
>>>>>>>>>
>>>>>>>>>> For the point 2 we need to clarify if it could applies to
>>>>>>>>>> trunk also. I'd now tend to avoid differences between trunk
>>>>>>>>>> and branch releases, at the functionality or other levels.
>>>>>>>>> I agree that the same settings should be maintained in the
>>>>>>>>> trunk and in the release branches.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Move The Asset Maintenance Component To A Separate Project
Posted by Ron Wheeler <rw...@artifact-software.com>.
No need to fork the project. Let's keep it within Apache.
On 28/11/2014 11:20 AM, Adrian Crum wrote:
> As has been discussed in this thread, we can spin off special purpose
> components to their own projects - where they can form their own
> communities and support structure.
>
> I am willing to use the Asset Maintenance component as a trial run.
> Here are some of my initial thoughts, comments are welcome:
>
> 1. Check with the ASF legal department before doing anything.
> 2. Create a project on a popular hosting site (like SourceForge, but
> it could be anywhere).
Why not use the Apache site?
http://git.apache.org/ has a Git repo for OfBiz
git://git.apache.org/ofbiz.git
> 3. Set up initial committers.
> 4. Notify the OFBiz mailing lists about the new project.
> 5. Drop the Asset Maintenance component from the ASF repo.
>
> The component would maintain the ASL 2 license. Support for various
> versions of OFBiz will be decided by the Asset Maintenance community.
>
> If the spin-off is a success, then all is good. If it fails, then the
> Asset Maintenance component is added back to the ASF repo.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 11/28/2014 4:01 PM, Ron Wheeler wrote:
>> The components not supported as part of the core and framework would not
>> leave Apache.
>> They become separate sub-projects under OFBiz so that they stay in the
>> community but are released and supported separately so that there is
>> more transparency about their state.
>> The release of new core and framework versions gets easier.
>>
>> The implied warranties get clearer and the sub-communities supporting
>> each of the non-core components are :
>> -easier to identify
>> - free to set their own roadmaps based on the needs and the resources
>> - easier to join since you only need to learn a small set of code in
>> order to contribute
>> - do not affect the core and framework code, roadmap or release plans
>> except when they request extensions to the core or framework through
>> JIRA issues.
>>
>> The core and framework team will not have to worry about the side
>> components unless they belong to the sub-project and can release with a
>> full warranty.
>>
>> Ron
>>
>>
>> On 28/11/2014 10:30 AM, gil portenseigne wrote:
>>> First I might be a bit confuse in this email, sorry for that, quite
>>> ideas came up while writing it, some organization missing.
>>>
>>> Le 28/11/2014 14:31, Ron Wheeler a écrit :
>>>> What is the downside if the non-core components are released on their
>>>> own with a clear set of documentation that describes the state of the
>>>> component?
>>> I guess there is none at first glance, it's quite the same idea :
>>> - A big release with core components active, and non-core component
>>> unactive (with included documentations)
>>> A monolythique one, all-included...
>>>
>>> - A Core release, first with then optional non-core component releases
>>> with their own documentations
>>> A core with packages. Less heavy but more actions... not a problem
>>>
>>> The things that make me wonder, and that's we try to achieve for
>>> several years with an extension management tool, are all the deviance
>>> possible without the control of such an Apache project.
>>>
>>> It is Out of Apache ! The component community can build their own
>>> component at the speed they need (often dependant on a personal
>>> project), without the quality control. It's good for this side
>>> community, we are already doing that in our way. But can lead to a
>>> branch component, which can't be contributed anymore to OFBiz if
>>> needed (for any reasons I guess).
>>>
>>> Why not stick with Apache OFBiz in contributing more, into
>>> desactivated non-core component using the side community advancement,
>>> and managing to level up these non-core quality too make them stable
>>> and reliable into Apache OFBiz.
>>>
>>> Specifics devs that can't be contributed into OFBiz, will remain as
>>> extension into the side community.
>>>
>>> If side community meets some deviance in his evolution, not following
>>> Apache OFBiz way, it must not have consequences like removing these
>>> non-core component from trunk or branches.
>>>
>>> That's why i like the idea to have in Apache OFBiz, release with
>>> unactive components (which can always be used and follow the Ofbiz
>>> way), and then everyone have the opportunity to offer other community
>>> components to replace unactive one, or to add to the core.
>>>
>>> Then some questions remains :
>>> - How can user be informed of such side communities from the OFBiz
>>> official site ? Is that possible ?
>>> - We tried to introduce a new tool to manage extension (which could be
>>> a solution for the first question, becoming a tool of indexation ) to
>>> serve this kind of purpose, but their wasn't much reactions to it. Cf
>>> : http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
>>>
>>>
>>> Gil
>>>
>>>>
>>>> My feeling is that it is better to release a clean core and framework
>>>> where ALL component are "warranteed" by the team to be tested and
>>>> supported.
>>>> Components that are not part of the core would be released on their
>>>> own with the warranty and support specified on an individual basis.
>>>>
>>>> At least the user community would know where it stands if it depends
>>>> a non-core component to run their business.
>>>>
>>>> I think this is preferable than releasing a big conglomeration of
>>>> working and non-working software that the user has to sort through to
>>>> figure out if they can make a usable OFBiz.
>>>>
>>>> It also simplifies the release process for the core and framework.
>>>>
>>>> Ron
>>>>
>>>> On 28/11/2014 7:18 AM, gil portenseigne wrote:
>>>>> Hello all !
>>>>>
>>>>> I followed the discussion, a bit late :
>>>>>
>>>>> Le 28/11/2014 11:24, Jacques Le Roux a écrit :
>>>>>> Afterthought: we agreed about having the same setting in both the
>>>>>> releases branches and the trunk. So if we disable a component in
>>>>>> the releases branches it will be also in the trunk.
>>>>>> Then, even we enable tests, we will not be aware of UI related
>>>>>> issues and globally all those which are no covered by tests. Apart
>>>>>> if an users enable the component and report issues.
>>>>>>
>>>>>> This might be a compromise, but we need our users to be aware of.
>>>>>> So they will need to be warned in the download page IMO.
>>>>>>
>>>>> I think it's a good compromise, warning is needed to ensure that
>>>>> user is aware or possible disfunctionment within these components.
>>>>> No tricks needed anymore to import components from trunk. Good
>>>>> enough for me.
>>>>>
>>>>> My opinion is that OOTB functionnalities are usable but rarely
>>>>> sufficient for End-User, advanced skills are needed in each project
>>>>> to make OFBiz fit the needs. So i guess there is no harm to let
>>>>> inactive (uncomplete or so) component at disposal for user who might
>>>>> need them.
>>>>>> Also if you remember this thread started with my idea of creating a
>>>>>> wiki page to explain to our users the alternative strategy of using
>>>>>> release branches rather than released packages.
>>>>>> I'd like to have a direct link to this wiki page from the download
>>>>>> page. This link name could be simply "alternative strategy". What
>>>>>> do you think?
>>>>> Using the same method, i like the idea.
>>>>>
>>>>> Gil
>>>>>>
>>>>>> I will stop this thread here and will create a new thread to
>>>>>> discuss the modality of putting back the specialpurpose components
>>>>>> in the R13.07 branch.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 27/11/2014 23:38, Jacques Le Roux a écrit :
>>>>>>> That sounds like a good enough solution to me
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 27/11/2014 19:41, Jacopo Cappellato a écrit :
>>>>>>>> This is a good point. We could find a way to programmatically
>>>>>>>> enable/disable the components just for the test run:
>>>>>>>>
>>>>>>>> ./ant -Denable-all=true clean-all load-demo run-tests
>>>>>>>>
>>>>>>>> but this is just an idea; we could figure out the best way to go.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 27, 2014, at 7:14 PM, Adrian Crum
>>>>>>>> <ad...@sandglass-software.com> wrote:
>>>>>>>>
>>>>>>>>> Be aware that disabling a component does two things:
>>>>>>>>>
>>>>>>>>> 1. Speeds up unit tests because the disabled component is
>>>>>>>>> excluded from them.
>>>>>>>>> 2. Increases the chance of regressions because the disabled
>>>>>>>>> component is not being tested.
>>>>>>>>>
>>>>>>>>> Adrian Crum
>>>>>>>>> Sandglass Software
>>>>>>>>> www.sandglass-software.com
>>>>>>>>>
>>>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
>>>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux
>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Yes, so we need to define which are those components. So 3
>>>>>>>>>>> points, which should be discussed separately it seems, not
>>>>>>>>>>> sure of the order yet but probably this one
>>>>>>>>>>> 1) Components to move to Attic. They will be freezed but still
>>>>>>>>>>> available in this state in Attic (in other words slowly dying)
>>>>>>>>>>> 2) Components to disable. They will be maintained, but OOTB
>>>>>>>>>>> will not interfere with other components (applications or
>>>>>>>>>>> other specialpurpose)
>>>>>>>>>>> 3) Components to keep enabled. They must be maintained and
>>>>>>>>>>> have no interactions with other components
>>>>>>>>>> Components enabled and disabled must be maintained in the same
>>>>>>>>>> way: it is not that a group is more important than the other.
>>>>>>>>>> Also, disabling a component doesn't mean that it will not go in
>>>>>>>>>> a release: we could have disabled components in releases and
>>>>>>>>>> enabled components excluded from a release or vice versa.
>>>>>>>>>>
>>>>>>>>>>> For the point 2 we need to clarify if it could applies to
>>>>>>>>>>> trunk also. I'd now tend to avoid differences between trunk
>>>>>>>>>>> and branch releases, at the functionality or other levels.
>>>>>>>>>> I agree that the same settings should be maintained in the
>>>>>>>>>> trunk and in the release branches.
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move The Asset Maintenance Component To A Separate Project
Posted by Anil Patel <an...@hotwaxmedia.com>.
Yes, I do have interest in asset maintenance application and I like the idea and direction proposed by Adrian.
With time I will figure out ways to support this experiment.
Anil Patel.
> On Nov 29, 2014, at 4:37 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>
> Le 29/11/2014 06:26, Jacopo Cappellato a écrit :
>> On Nov 28, 2014, at 5:20 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>>
>>> 1. Check with the ASF legal department before doing anything.
>> You can do step #1 without any approval from the ASF or the OFBiz project.
>>
>>> 2. Create a project on a popular hosting site (like SourceForge, but it could be anywhere).
>>> 3. Set up initial committers.
>>> 4. Notify the OFBiz mailing lists about the new project.
>>> 5. Drop the Asset Maintenance component from the ASF repo.
>> Just to avoid confusion, let's keep step #5 out of this plan: the decision of dropping the original component or not will be taken by the OFBiz community based on several factors (its value, if it is maintained, etc... of course knowing that there is a maintained version of it with the same license will be a relevant factor in the decision).
>
> Thanks Jacopo, I wanted to say the same. Anil created this component so I guess he has still some interest in it.
>
> Jacques
>
>>
>> Jacopo
>>
Re: Move The Asset Maintenance Component To A Separate Project
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 29/11/2014 06:26, Jacopo Cappellato a écrit :
> On Nov 28, 2014, at 5:20 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>
>> 1. Check with the ASF legal department before doing anything.
> You can do step #1 without any approval from the ASF or the OFBiz project.
>
>> 2. Create a project on a popular hosting site (like SourceForge, but it could be anywhere).
>> 3. Set up initial committers.
>> 4. Notify the OFBiz mailing lists about the new project.
>> 5. Drop the Asset Maintenance component from the ASF repo.
> Just to avoid confusion, let's keep step #5 out of this plan: the decision of dropping the original component or not will be taken by the OFBiz community based on several factors (its value, if it is maintained, etc... of course knowing that there is a maintained version of it with the same license will be a relevant factor in the decision).
Thanks Jacopo, I wanted to say the same. Anil created this component so I guess he has still some interest in it.
Jacques
>
> Jacopo
>
Re: Move The Asset Maintenance Component To A Separate Project
Posted by Adrian Crum <ad...@sandglass-software.com>.
Good point, thanks!
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 11/29/2014 5:26 AM, Jacopo Cappellato wrote:
> On Nov 28, 2014, at 5:20 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>
>> 1. Check with the ASF legal department before doing anything.
>
> You can do step #1 without any approval from the ASF or the OFBiz project.
>
>> 2. Create a project on a popular hosting site (like SourceForge, but it could be anywhere).
>> 3. Set up initial committers.
>> 4. Notify the OFBiz mailing lists about the new project.
>> 5. Drop the Asset Maintenance component from the ASF repo.
>
> Just to avoid confusion, let's keep step #5 out of this plan: the decision of dropping the original component or not will be taken by the OFBiz community based on several factors (its value, if it is maintained, etc... of course knowing that there is a maintained version of it with the same license will be a relevant factor in the decision).
>
> Jacopo
>
Re: Move The Asset Maintenance Component To A Separate Project (was: Suggest branch rather than release strategy?)
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Nov 28, 2014, at 5:20 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
> 1. Check with the ASF legal department before doing anything.
You can do step #1 without any approval from the ASF or the OFBiz project.
> 2. Create a project on a popular hosting site (like SourceForge, but it could be anywhere).
> 3. Set up initial committers.
> 4. Notify the OFBiz mailing lists about the new project.
> 5. Drop the Asset Maintenance component from the ASF repo.
Just to avoid confusion, let's keep step #5 out of this plan: the decision of dropping the original component or not will be taken by the OFBiz community based on several factors (its value, if it is maintained, etc... of course knowing that there is a maintained version of it with the same license will be a relevant factor in the decision).
Jacopo
Re: Move The Asset Maintenance Component To A Separate Project
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 28/11/2014 10:14 PM, Scott Gray wrote:
> Yeah I understood that. Deleting simply means it won't be available
> in future releases. It wouldn't suddenly disappear out of
> pre-existing releases.
Got it.
>
> Regards
> Scott
>
> On Sat, Nov 29, 2014 at 3:49 PM, Ron Wheeler
> <rwheeler@artifact-software.com
> <ma...@artifact-software.com>> wrote:
>
> On 28/11/2014 9:38 PM, Scott Gray wrote:
>
> OFBiz itself went through that on a much larger scale when
> joining the ASF.
> It took some time but it wasn't a big deal.
>
> No users are forced to do anything other than make a choice:
> stick with
> what you have or change to what is now available. Open source
> users make
> these types of decisions on a regular basis.
>
> Your statement is generally are correct but in this context, it
> related to the suggestion about (#5) deleting Asset Management
> from OFBiz.
>
> Regards
> Scott
> On 29 Nov 2014 14:51, "Ron Wheeler"
> <rwheeler@artifact-software.com
> <ma...@artifact-software.com>> wrote:
>
> Don't forget to get ICLAs and Corporate CLAs for the new
> site for each
> contributor otherwise you will have trouble if you want to
> submit it to
> Apache OFBiz in the future.
> I guess that if you offer it under an Apache license
> without having an
> ICLA /CCLA in place, you would be personally liable for
> any claim by
> contributors in the future.
>
> Not sure that you can/should force any existing users to
> move to the new
> project.
> Perhaps no one is using it so #5 is not a problem but I am
> not sure how
> you can reach all of the people who have downloaded it.
>
> Ron
>
> On 28/11/2014 7:54 PM, Scott Gray wrote:
>
> Hi Adrian,
>
> Sounds like a good plan to me. I think there should
> probably be some sort
> of a delay in step #5 and it should ultimately be
> decided by a PMC vote at
> that point in time as well. I totally support the
> concept though.
>
> Regards
> Scott
>
> On Sat, Nov 29, 2014 at 5:20 AM, Adrian Crum <
> adrian.crum@sandglass-software.com
> <ma...@sandglass-software.com>> wrote:
>
> As has been discussed in this thread, we can spin
> off special purpose
>
> components to their own projects - where they can
> form their own
> communities and support structure.
>
> I am willing to use the Asset Maintenance
> component as a trial run. Here
> are some of my initial thoughts, comments are welcome:
>
> 1. Check with the ASF legal department before
> doing anything.
> 2. Create a project on a popular hosting site
> (like SourceForge, but it
> could be anywhere).
> 3. Set up initial committers.
> 4. Notify the OFBiz mailing lists about the new
> project.
> 5. Drop the Asset Maintenance component from the
> ASF repo.
>
> The component would maintain the ASL 2 license.
> Support for various
> versions of OFBiz will be decided by the Asset
> Maintenance community.
>
> If the spin-off is a success, then all is good. If
> it fails, then the
> Asset Maintenance component is added back to the
> ASF repo.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
> <http://www.sandglass-software.com>
>
> On 11/28/2014 4:01 PM, Ron Wheeler wrote:
>
> The components not supported as part of the core
> and framework would not
>
> leave Apache.
> They become separate sub-projects under OFBiz
> so that they stay in the
> community but are released and supported
> separately so that there is
> more transparency about their state.
> The release of new core and framework versions
> gets easier.
>
> The implied warranties get clearer and the
> sub-communities supporting
> each of the non-core components are :
> -easier to identify
> - free to set their own roadmaps based on the
> needs and the resources
> - easier to join since you only need to learn
> a small set of code in
> order to contribute
> - do not affect the core and framework code,
> roadmap or release plans
> except when they request extensions to the
> core or framework through
> JIRA issues.
>
> The core and framework team will not have to
> worry about the side
> components unless they belong to the
> sub-project and can release with a
> full warranty.
>
> Ron
>
>
> On 28/11/2014 10:30 AM, gil portenseigne wrote:
>
> First I might be a bit confuse in this
> email, sorry for that, quite
>
> ideas came up while writing it, some
> organization missing.
>
> Le 28/11/2014 14:31, Ron Wheeler a écrit :
>
> What is the downside if the non-core
> components are released on their
>
> own with a clear set of documentation
> that describes the state of the
> component?
>
> I guess there is none at first
> glance, it's quite the same idea :
>
> - A big release with core components
> active, and non-core component
> unactive (with included documentations)
> A monolythique one, all-included...
>
> - A Core release, first with then optional
> non-core component releases
> with their own documentations
> A core with packages. Less heavy but more
> actions... not a problem
>
> The things that make me wonder, and that's
> we try to achieve for
> several years with an extension management
> tool, are all the deviance
> possible without the control of such an
> Apache project.
>
> It is Out of Apache ! The component
> community can build their own
> component at the speed they need (often
> dependant on a personal
> project), without the quality control.
> It's good for this side
> community, we are already doing that in
> our way. But can lead to a
> branch component, which can't be
> contributed anymore to OFBiz if
> needed (for any reasons I guess).
>
> Why not stick with Apache OFBiz in
> contributing more, into
> desactivated non-core component using the
> side community advancement,
> and managing to level up these non-core
> quality too make them stable
> and reliable into Apache OFBiz.
>
> Specifics devs that can't be contributed
> into OFBiz, will remain as
> extension into the side community.
>
> If side community meets some deviance in
> his evolution, not following
> Apache OFBiz way, it must not have
> consequences like removing these
> non-core component from trunk or branches.
>
> That's why i like the idea to have in
> Apache OFBiz, release with
> unactive components (which can always be
> used and follow the Ofbiz
> way), and then everyone have the
> opportunity to offer other community
> components to replace unactive one, or to
> add to the core.
>
> Then some questions remains :
> - How can user be informed of such side
> communities from the OFBiz
> official site ? Is that possible ?
> - We tried to introduce a new tool to
> manage extension (which could be
> a solution for the first question,
> becoming a tool of indexation ) to
> serve this kind of purpose, but their
> wasn't much reactions to it. Cf
> :
> http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
>
>
> Gil
>
>
> My feeling is that it is better to
> release a clean core and framework
>
> where ALL component are "warranteed"
> by the team to be tested and
> supported.
> Components that are not part of the
> core would be released on their
> own with the warranty and support
> specified on an individual basis.
>
> At least the user community would know
> where it stands if it depends
> a non-core component to run their
> business.
>
> I think this is preferable than
> releasing a big conglomeration of
> working and non-working software that
> the user has to sort through to
> figure out if they can make a usable
> OFBiz.
>
> It also simplifies the release process
> for the core and framework.
>
> Ron
>
> On 28/11/2014 7:18 AM, gil
> portenseigne wrote:
>
> Hello all !
>
> I followed the discussion, a bit
> late :
>
> Le 28/11/2014 11:24, Jacques Le
> Roux a écrit :
>
> Afterthought: we agreed about
> having the same setting in both the
>
> releases branches and the
> trunk. So if we disable a
> component in
> the releases branches it will
> be also in the trunk.
> Then, even we enable tests, we
> will not be aware of UI related
> issues and globally all those
> which are no covered by tests.
> Apart
> if an users enable the
> component and report issues.
>
> This might be a compromise,
> but we need our users to be
> aware of.
> So they will need to be warned
> in the download page IMO.
>
> I think it's a good
> compromise, warning is needed
> to ensure that
>
> user is aware or possible
> disfunctionment within these
> components.
> No tricks needed anymore to import
> components from trunk. Good
> enough for me.
>
> My opinion is that OOTB
> functionnalities are usable but rarely
> sufficient for End-User, advanced
> skills are needed in each project
> to make OFBiz fit the needs. So i
> guess there is no harm to let
> inactive (uncomplete or so)
> component at disposal for user who
> might
> need them.
>
> Also if you remember this thread
> started with my idea of creating a
>
> wiki page to explain to our
> users the alternative strategy
> of using
> release branches rather than
> released packages.
> I'd like to have a direct link
> to this wiki page from the
> download
> page. This link name could be
> simply "alternative strategy".
> What
> do you think?
>
> Using the same method, i
> like the idea.
>
> Gil
>
> I will stop this thread here and
> will create a new thread to
>
> discuss the modality of
> putting back the
> specialpurpose components
> in the R13.07 branch.
>
> Jacques
>
>
> Le 27/11/2014 23:38, Jacques
> Le Roux a écrit :
>
> That sounds like a good
> enough solution to me
>
> Jacques
>
> Le 27/11/2014 19:41,
> Jacopo Cappellato a écrit :
>
> This is a good point. We
> could find a way to
> programmatically
>
> enable/disable the
> components just for
> the test run:
>
> ./ant
> -Denable-all=true
> clean-all load-demo
> run-tests
>
> but this is just an
> idea; we could figure
> out the best way to go.
>
> Jacopo
>
>
> On Nov 27, 2014, at
> 7:14 PM, Adrian Crum
> <adrian.crum@sandglass-software.com
> <ma...@sandglass-software.com>>
> wrote:
>
> Be aware that
> disabling a component
> does two things:
>
> 1. Speeds up unit
> tests because the
> disabled component is
> excluded from them.
> 2. Increases the
> chance of
> regressions
> because the disabled
> component is not
> being tested.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
> <http://www.sandglass-software.com>
>
> On 11/27/2014 5:41
> PM, Jacopo
> Cappellato wrote:
>
> On Nov 27, 2014,
> at 6:25 PM,
> Jacques Le Roux
>
> <jacques.le.roux@les7arts.com
> <ma...@les7arts.com>>
> wrote:
>
> Yes, so we
> need to define
> which are
> those
> components. So 3
>
> points,
> which
> should be
> discussed
> separately
> it seems, not
> sure of
> the order
> yet but
> probably
> this one
> 1)
> Components
> to move to
> Attic.
> They will
> be freezed
> but still
> available
> in this
> state in
> Attic (in
> other
> words
> slowly dying)
> 2)
> Components
> to
> disable.
> They will
> be
> maintained, but
> OOTB
> will not
> interfere
> with other
> components
> (applications
> or
> other
> specialpurpose)
> 3)
> Components
> to keep
> enabled.
> They must
> be
> maintained and
> have no
> interactions
> with other
> components
>
>
> Components
> enabled
> and
> disabled
> must be
> maintained
> in the same
>
> way: it is not
> that a group
> is more
> important than
> the other.
> Also,
> disabling a
> component
> doesn't mean
> that it will
> not go in
> a release: we
> could have
> disabled
> components in
> releases and
> enabled
> components
> excluded from
> a release or
> vice versa.
>
> For the
> point 2 we
> need to
> clarify if it
> could applies to
>
> trunk
> also. I'd
> now tend
> to avoid
> differences between
> trunk
> and branch
> releases,
> at the
> functionality
> or other
> levels.
>
> I agree
> that the
> same
> settings
> should be
> maintained
> in the
>
> trunk and in
> the release
> branches.
>
> Jacopo
>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> <ma...@artifact-software.com>
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> <ma...@artifact-software.com>
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move The Asset Maintenance Component To A Separate Project
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Yeah I understood that. Deleting simply means it won't be available in
future releases. It wouldn't suddenly disappear out of pre-existing
releases.
Regards
Scott
On Sat, Nov 29, 2014 at 3:49 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:
> On 28/11/2014 9:38 PM, Scott Gray wrote:
>
>> OFBiz itself went through that on a much larger scale when joining the
>> ASF.
>> It took some time but it wasn't a big deal.
>>
>> No users are forced to do anything other than make a choice: stick with
>> what you have or change to what is now available. Open source users make
>> these types of decisions on a regular basis.
>>
> Your statement is generally are correct but in this context, it related to
> the suggestion about (#5) deleting Asset Management from OFBiz.
>
> Regards
>> Scott
>> On 29 Nov 2014 14:51, "Ron Wheeler" <rw...@artifact-software.com>
>> wrote:
>>
>> Don't forget to get ICLAs and Corporate CLAs for the new site for each
>>> contributor otherwise you will have trouble if you want to submit it to
>>> Apache OFBiz in the future.
>>> I guess that if you offer it under an Apache license without having an
>>> ICLA /CCLA in place, you would be personally liable for any claim by
>>> contributors in the future.
>>>
>>> Not sure that you can/should force any existing users to move to the new
>>> project.
>>> Perhaps no one is using it so #5 is not a problem but I am not sure how
>>> you can reach all of the people who have downloaded it.
>>>
>>> Ron
>>>
>>> On 28/11/2014 7:54 PM, Scott Gray wrote:
>>>
>>> Hi Adrian,
>>>>
>>>> Sounds like a good plan to me. I think there should probably be some
>>>> sort
>>>> of a delay in step #5 and it should ultimately be decided by a PMC vote
>>>> at
>>>> that point in time as well. I totally support the concept though.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On Sat, Nov 29, 2014 at 5:20 AM, Adrian Crum <
>>>> adrian.crum@sandglass-software.com> wrote:
>>>>
>>>> As has been discussed in this thread, we can spin off special purpose
>>>>
>>>>> components to their own projects - where they can form their own
>>>>> communities and support structure.
>>>>>
>>>>> I am willing to use the Asset Maintenance component as a trial run.
>>>>> Here
>>>>> are some of my initial thoughts, comments are welcome:
>>>>>
>>>>> 1. Check with the ASF legal department before doing anything.
>>>>> 2. Create a project on a popular hosting site (like SourceForge, but it
>>>>> could be anywhere).
>>>>> 3. Set up initial committers.
>>>>> 4. Notify the OFBiz mailing lists about the new project.
>>>>> 5. Drop the Asset Maintenance component from the ASF repo.
>>>>>
>>>>> The component would maintain the ASL 2 license. Support for various
>>>>> versions of OFBiz will be decided by the Asset Maintenance community.
>>>>>
>>>>> If the spin-off is a success, then all is good. If it fails, then the
>>>>> Asset Maintenance component is added back to the ASF repo.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 11/28/2014 4:01 PM, Ron Wheeler wrote:
>>>>>
>>>>> The components not supported as part of the core and framework would
>>>>> not
>>>>>
>>>>>> leave Apache.
>>>>>> They become separate sub-projects under OFBiz so that they stay in the
>>>>>> community but are released and supported separately so that there is
>>>>>> more transparency about their state.
>>>>>> The release of new core and framework versions gets easier.
>>>>>>
>>>>>> The implied warranties get clearer and the sub-communities supporting
>>>>>> each of the non-core components are :
>>>>>> -easier to identify
>>>>>> - free to set their own roadmaps based on the needs and the resources
>>>>>> - easier to join since you only need to learn a small set of code in
>>>>>> order to contribute
>>>>>> - do not affect the core and framework code, roadmap or release plans
>>>>>> except when they request extensions to the core or framework through
>>>>>> JIRA issues.
>>>>>>
>>>>>> The core and framework team will not have to worry about the side
>>>>>> components unless they belong to the sub-project and can release with
>>>>>> a
>>>>>> full warranty.
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>>
>>>>>> On 28/11/2014 10:30 AM, gil portenseigne wrote:
>>>>>>
>>>>>> First I might be a bit confuse in this email, sorry for that, quite
>>>>>>
>>>>>>> ideas came up while writing it, some organization missing.
>>>>>>>
>>>>>>> Le 28/11/2014 14:31, Ron Wheeler a écrit :
>>>>>>>
>>>>>>> What is the downside if the non-core components are released on
>>>>>>> their
>>>>>>>
>>>>>>>> own with a clear set of documentation that describes the state of
>>>>>>>> the
>>>>>>>> component?
>>>>>>>>
>>>>>>>> I guess there is none at first glance, it's quite the same idea :
>>>>>>>>
>>>>>>> - A big release with core components active, and non-core component
>>>>>>> unactive (with included documentations)
>>>>>>> A monolythique one, all-included...
>>>>>>>
>>>>>>> - A Core release, first with then optional non-core component
>>>>>>> releases
>>>>>>> with their own documentations
>>>>>>> A core with packages. Less heavy but more actions... not a problem
>>>>>>>
>>>>>>> The things that make me wonder, and that's we try to achieve for
>>>>>>> several years with an extension management tool, are all the deviance
>>>>>>> possible without the control of such an Apache project.
>>>>>>>
>>>>>>> It is Out of Apache ! The component community can build their own
>>>>>>> component at the speed they need (often dependant on a personal
>>>>>>> project), without the quality control. It's good for this side
>>>>>>> community, we are already doing that in our way. But can lead to a
>>>>>>> branch component, which can't be contributed anymore to OFBiz if
>>>>>>> needed (for any reasons I guess).
>>>>>>>
>>>>>>> Why not stick with Apache OFBiz in contributing more, into
>>>>>>> desactivated non-core component using the side community advancement,
>>>>>>> and managing to level up these non-core quality too make them stable
>>>>>>> and reliable into Apache OFBiz.
>>>>>>>
>>>>>>> Specifics devs that can't be contributed into OFBiz, will remain as
>>>>>>> extension into the side community.
>>>>>>>
>>>>>>> If side community meets some deviance in his evolution, not following
>>>>>>> Apache OFBiz way, it must not have consequences like removing these
>>>>>>> non-core component from trunk or branches.
>>>>>>>
>>>>>>> That's why i like the idea to have in Apache OFBiz, release with
>>>>>>> unactive components (which can always be used and follow the Ofbiz
>>>>>>> way), and then everyone have the opportunity to offer other community
>>>>>>> components to replace unactive one, or to add to the core.
>>>>>>>
>>>>>>> Then some questions remains :
>>>>>>> - How can user be informed of such side communities from the OFBiz
>>>>>>> official site ? Is that possible ?
>>>>>>> - We tried to introduce a new tool to manage extension (which could
>>>>>>> be
>>>>>>> a solution for the first question, becoming a tool of indexation ) to
>>>>>>> serve this kind of purpose, but their wasn't much reactions to it. Cf
>>>>>>> : http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
>>>>>>>
>>>>>>>
>>>>>>> Gil
>>>>>>>
>>>>>>>
>>>>>>> My feeling is that it is better to release a clean core and
>>>>>>> framework
>>>>>>>
>>>>>>>> where ALL component are "warranteed" by the team to be tested and
>>>>>>>> supported.
>>>>>>>> Components that are not part of the core would be released on their
>>>>>>>> own with the warranty and support specified on an individual basis.
>>>>>>>>
>>>>>>>> At least the user community would know where it stands if it depends
>>>>>>>> a non-core component to run their business.
>>>>>>>>
>>>>>>>> I think this is preferable than releasing a big conglomeration of
>>>>>>>> working and non-working software that the user has to sort through
>>>>>>>> to
>>>>>>>> figure out if they can make a usable OFBiz.
>>>>>>>>
>>>>>>>> It also simplifies the release process for the core and framework.
>>>>>>>>
>>>>>>>> Ron
>>>>>>>>
>>>>>>>> On 28/11/2014 7:18 AM, gil portenseigne wrote:
>>>>>>>>
>>>>>>>> Hello all !
>>>>>>>>
>>>>>>>>> I followed the discussion, a bit late :
>>>>>>>>>
>>>>>>>>> Le 28/11/2014 11:24, Jacques Le Roux a écrit :
>>>>>>>>>
>>>>>>>>> Afterthought: we agreed about having the same setting in both the
>>>>>>>>>
>>>>>>>>>> releases branches and the trunk. So if we disable a component in
>>>>>>>>>> the releases branches it will be also in the trunk.
>>>>>>>>>> Then, even we enable tests, we will not be aware of UI related
>>>>>>>>>> issues and globally all those which are no covered by tests. Apart
>>>>>>>>>> if an users enable the component and report issues.
>>>>>>>>>>
>>>>>>>>>> This might be a compromise, but we need our users to be aware of.
>>>>>>>>>> So they will need to be warned in the download page IMO.
>>>>>>>>>>
>>>>>>>>>> I think it's a good compromise, warning is needed to ensure
>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>>> user is aware or possible disfunctionment within these
>>>>>>>>> components.
>>>>>>>>> No tricks needed anymore to import components from trunk. Good
>>>>>>>>> enough for me.
>>>>>>>>>
>>>>>>>>> My opinion is that OOTB functionnalities are usable but rarely
>>>>>>>>> sufficient for End-User, advanced skills are needed in each project
>>>>>>>>> to make OFBiz fit the needs. So i guess there is no harm to let
>>>>>>>>> inactive (uncomplete or so) component at disposal for user who
>>>>>>>>> might
>>>>>>>>> need them.
>>>>>>>>>
>>>>>>>>> Also if you remember this thread started with my idea of
>>>>>>>>> creating a
>>>>>>>>>
>>>>>>>>>> wiki page to explain to our users the alternative strategy of
>>>>>>>>>> using
>>>>>>>>>> release branches rather than released packages.
>>>>>>>>>> I'd like to have a direct link to this wiki page from the download
>>>>>>>>>> page. This link name could be simply "alternative strategy". What
>>>>>>>>>> do you think?
>>>>>>>>>>
>>>>>>>>>> Using the same method, i like the idea.
>>>>>>>>>>
>>>>>>>>> Gil
>>>>>>>>>
>>>>>>>>> I will stop this thread here and will create a new thread to
>>>>>>>>>
>>>>>>>>>> discuss the modality of putting back the specialpurpose components
>>>>>>>>>> in the R13.07 branch.
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 27/11/2014 23:38, Jacques Le Roux a écrit :
>>>>>>>>>>
>>>>>>>>>> That sounds like a good enough solution to me
>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>> Le 27/11/2014 19:41, Jacopo Cappellato a écrit :
>>>>>>>>>>>
>>>>>>>>>>> This is a good point. We could find a way to programmatically
>>>>>>>>>>>
>>>>>>>>>>>> enable/disable the components just for the test run:
>>>>>>>>>>>>
>>>>>>>>>>>> ./ant -Denable-all=true clean-all load-demo run-tests
>>>>>>>>>>>>
>>>>>>>>>>>> but this is just an idea; we could figure out the best way to
>>>>>>>>>>>> go.
>>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Nov 27, 2014, at 7:14 PM, Adrian Crum
>>>>>>>>>>>> <ad...@sandglass-software.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Be aware that disabling a component does two things:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Speeds up unit tests because the disabled component is
>>>>>>>>>>>>> excluded from them.
>>>>>>>>>>>>> 2. Increases the chance of regressions because the disabled
>>>>>>>>>>>>> component is not being tested.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Adrian Crum
>>>>>>>>>>>>> Sandglass Software
>>>>>>>>>>>>> www.sandglass-software.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux
>>>>>>>>>>>>>
>>>>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, so we need to define which are those components. So 3
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> points, which should be discussed separately it seems, not
>>>>>>>>>>>>>>> sure of the order yet but probably this one
>>>>>>>>>>>>>>> 1) Components to move to Attic. They will be freezed but
>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>> available in this state in Attic (in other words slowly
>>>>>>>>>>>>>>> dying)
>>>>>>>>>>>>>>> 2) Components to disable. They will be maintained, but OOTB
>>>>>>>>>>>>>>> will not interfere with other components (applications or
>>>>>>>>>>>>>>> other specialpurpose)
>>>>>>>>>>>>>>> 3) Components to keep enabled. They must be maintained and
>>>>>>>>>>>>>>> have no interactions with other components
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Components enabled and disabled must be maintained in the
>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> way: it is not that a group is more important than the other.
>>>>>>>>>>>>>> Also, disabling a component doesn't mean that it will not go
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> a release: we could have disabled components in releases and
>>>>>>>>>>>>>> enabled components excluded from a release or vice versa.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For the point 2 we need to clarify if it could applies to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> trunk also. I'd now tend to avoid differences between trunk
>>>>>>>>>>>>>>> and branch releases, at the functionality or other levels.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I agree that the same settings should be maintained in the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> trunk and in the release branches.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Re: Move The Asset Maintenance Component To A Separate Project
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 28/11/2014 9:38 PM, Scott Gray wrote:
> OFBiz itself went through that on a much larger scale when joining the ASF.
> It took some time but it wasn't a big deal.
>
> No users are forced to do anything other than make a choice: stick with
> what you have or change to what is now available. Open source users make
> these types of decisions on a regular basis.
Your statement is generally are correct but in this context, it related
to the suggestion about (#5) deleting Asset Management from OFBiz.
> Regards
> Scott
> On 29 Nov 2014 14:51, "Ron Wheeler" <rw...@artifact-software.com> wrote:
>
>> Don't forget to get ICLAs and Corporate CLAs for the new site for each
>> contributor otherwise you will have trouble if you want to submit it to
>> Apache OFBiz in the future.
>> I guess that if you offer it under an Apache license without having an
>> ICLA /CCLA in place, you would be personally liable for any claim by
>> contributors in the future.
>>
>> Not sure that you can/should force any existing users to move to the new
>> project.
>> Perhaps no one is using it so #5 is not a problem but I am not sure how
>> you can reach all of the people who have downloaded it.
>>
>> Ron
>>
>> On 28/11/2014 7:54 PM, Scott Gray wrote:
>>
>>> Hi Adrian,
>>>
>>> Sounds like a good plan to me. I think there should probably be some sort
>>> of a delay in step #5 and it should ultimately be decided by a PMC vote at
>>> that point in time as well. I totally support the concept though.
>>>
>>> Regards
>>> Scott
>>>
>>> On Sat, Nov 29, 2014 at 5:20 AM, Adrian Crum <
>>> adrian.crum@sandglass-software.com> wrote:
>>>
>>> As has been discussed in this thread, we can spin off special purpose
>>>> components to their own projects - where they can form their own
>>>> communities and support structure.
>>>>
>>>> I am willing to use the Asset Maintenance component as a trial run. Here
>>>> are some of my initial thoughts, comments are welcome:
>>>>
>>>> 1. Check with the ASF legal department before doing anything.
>>>> 2. Create a project on a popular hosting site (like SourceForge, but it
>>>> could be anywhere).
>>>> 3. Set up initial committers.
>>>> 4. Notify the OFBiz mailing lists about the new project.
>>>> 5. Drop the Asset Maintenance component from the ASF repo.
>>>>
>>>> The component would maintain the ASL 2 license. Support for various
>>>> versions of OFBiz will be decided by the Asset Maintenance community.
>>>>
>>>> If the spin-off is a success, then all is good. If it fails, then the
>>>> Asset Maintenance component is added back to the ASF repo.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 11/28/2014 4:01 PM, Ron Wheeler wrote:
>>>>
>>>> The components not supported as part of the core and framework would not
>>>>> leave Apache.
>>>>> They become separate sub-projects under OFBiz so that they stay in the
>>>>> community but are released and supported separately so that there is
>>>>> more transparency about their state.
>>>>> The release of new core and framework versions gets easier.
>>>>>
>>>>> The implied warranties get clearer and the sub-communities supporting
>>>>> each of the non-core components are :
>>>>> -easier to identify
>>>>> - free to set their own roadmaps based on the needs and the resources
>>>>> - easier to join since you only need to learn a small set of code in
>>>>> order to contribute
>>>>> - do not affect the core and framework code, roadmap or release plans
>>>>> except when they request extensions to the core or framework through
>>>>> JIRA issues.
>>>>>
>>>>> The core and framework team will not have to worry about the side
>>>>> components unless they belong to the sub-project and can release with a
>>>>> full warranty.
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>> On 28/11/2014 10:30 AM, gil portenseigne wrote:
>>>>>
>>>>> First I might be a bit confuse in this email, sorry for that, quite
>>>>>> ideas came up while writing it, some organization missing.
>>>>>>
>>>>>> Le 28/11/2014 14:31, Ron Wheeler a écrit :
>>>>>>
>>>>>> What is the downside if the non-core components are released on their
>>>>>>> own with a clear set of documentation that describes the state of the
>>>>>>> component?
>>>>>>>
>>>>>>> I guess there is none at first glance, it's quite the same idea :
>>>>>> - A big release with core components active, and non-core component
>>>>>> unactive (with included documentations)
>>>>>> A monolythique one, all-included...
>>>>>>
>>>>>> - A Core release, first with then optional non-core component releases
>>>>>> with their own documentations
>>>>>> A core with packages. Less heavy but more actions... not a problem
>>>>>>
>>>>>> The things that make me wonder, and that's we try to achieve for
>>>>>> several years with an extension management tool, are all the deviance
>>>>>> possible without the control of such an Apache project.
>>>>>>
>>>>>> It is Out of Apache ! The component community can build their own
>>>>>> component at the speed they need (often dependant on a personal
>>>>>> project), without the quality control. It's good for this side
>>>>>> community, we are already doing that in our way. But can lead to a
>>>>>> branch component, which can't be contributed anymore to OFBiz if
>>>>>> needed (for any reasons I guess).
>>>>>>
>>>>>> Why not stick with Apache OFBiz in contributing more, into
>>>>>> desactivated non-core component using the side community advancement,
>>>>>> and managing to level up these non-core quality too make them stable
>>>>>> and reliable into Apache OFBiz.
>>>>>>
>>>>>> Specifics devs that can't be contributed into OFBiz, will remain as
>>>>>> extension into the side community.
>>>>>>
>>>>>> If side community meets some deviance in his evolution, not following
>>>>>> Apache OFBiz way, it must not have consequences like removing these
>>>>>> non-core component from trunk or branches.
>>>>>>
>>>>>> That's why i like the idea to have in Apache OFBiz, release with
>>>>>> unactive components (which can always be used and follow the Ofbiz
>>>>>> way), and then everyone have the opportunity to offer other community
>>>>>> components to replace unactive one, or to add to the core.
>>>>>>
>>>>>> Then some questions remains :
>>>>>> - How can user be informed of such side communities from the OFBiz
>>>>>> official site ? Is that possible ?
>>>>>> - We tried to introduce a new tool to manage extension (which could be
>>>>>> a solution for the first question, becoming a tool of indexation ) to
>>>>>> serve this kind of purpose, but their wasn't much reactions to it. Cf
>>>>>> : http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
>>>>>>
>>>>>>
>>>>>> Gil
>>>>>>
>>>>>>
>>>>>> My feeling is that it is better to release a clean core and framework
>>>>>>> where ALL component are "warranteed" by the team to be tested and
>>>>>>> supported.
>>>>>>> Components that are not part of the core would be released on their
>>>>>>> own with the warranty and support specified on an individual basis.
>>>>>>>
>>>>>>> At least the user community would know where it stands if it depends
>>>>>>> a non-core component to run their business.
>>>>>>>
>>>>>>> I think this is preferable than releasing a big conglomeration of
>>>>>>> working and non-working software that the user has to sort through to
>>>>>>> figure out if they can make a usable OFBiz.
>>>>>>>
>>>>>>> It also simplifies the release process for the core and framework.
>>>>>>>
>>>>>>> Ron
>>>>>>>
>>>>>>> On 28/11/2014 7:18 AM, gil portenseigne wrote:
>>>>>>>
>>>>>>> Hello all !
>>>>>>>> I followed the discussion, a bit late :
>>>>>>>>
>>>>>>>> Le 28/11/2014 11:24, Jacques Le Roux a écrit :
>>>>>>>>
>>>>>>>> Afterthought: we agreed about having the same setting in both the
>>>>>>>>> releases branches and the trunk. So if we disable a component in
>>>>>>>>> the releases branches it will be also in the trunk.
>>>>>>>>> Then, even we enable tests, we will not be aware of UI related
>>>>>>>>> issues and globally all those which are no covered by tests. Apart
>>>>>>>>> if an users enable the component and report issues.
>>>>>>>>>
>>>>>>>>> This might be a compromise, but we need our users to be aware of.
>>>>>>>>> So they will need to be warned in the download page IMO.
>>>>>>>>>
>>>>>>>>> I think it's a good compromise, warning is needed to ensure that
>>>>>>>>>
>>>>>>>> user is aware or possible disfunctionment within these components.
>>>>>>>> No tricks needed anymore to import components from trunk. Good
>>>>>>>> enough for me.
>>>>>>>>
>>>>>>>> My opinion is that OOTB functionnalities are usable but rarely
>>>>>>>> sufficient for End-User, advanced skills are needed in each project
>>>>>>>> to make OFBiz fit the needs. So i guess there is no harm to let
>>>>>>>> inactive (uncomplete or so) component at disposal for user who might
>>>>>>>> need them.
>>>>>>>>
>>>>>>>> Also if you remember this thread started with my idea of creating a
>>>>>>>>> wiki page to explain to our users the alternative strategy of using
>>>>>>>>> release branches rather than released packages.
>>>>>>>>> I'd like to have a direct link to this wiki page from the download
>>>>>>>>> page. This link name could be simply "alternative strategy". What
>>>>>>>>> do you think?
>>>>>>>>>
>>>>>>>>> Using the same method, i like the idea.
>>>>>>>> Gil
>>>>>>>>
>>>>>>>> I will stop this thread here and will create a new thread to
>>>>>>>>> discuss the modality of putting back the specialpurpose components
>>>>>>>>> in the R13.07 branch.
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 27/11/2014 23:38, Jacques Le Roux a écrit :
>>>>>>>>>
>>>>>>>>> That sounds like a good enough solution to me
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>> Le 27/11/2014 19:41, Jacopo Cappellato a écrit :
>>>>>>>>>>
>>>>>>>>>> This is a good point. We could find a way to programmatically
>>>>>>>>>>> enable/disable the components just for the test run:
>>>>>>>>>>>
>>>>>>>>>>> ./ant -Denable-all=true clean-all load-demo run-tests
>>>>>>>>>>>
>>>>>>>>>>> but this is just an idea; we could figure out the best way to go.
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Nov 27, 2014, at 7:14 PM, Adrian Crum
>>>>>>>>>>> <ad...@sandglass-software.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Be aware that disabling a component does two things:
>>>>>>>>>>>
>>>>>>>>>>>> 1. Speeds up unit tests because the disabled component is
>>>>>>>>>>>> excluded from them.
>>>>>>>>>>>> 2. Increases the chance of regressions because the disabled
>>>>>>>>>>>> component is not being tested.
>>>>>>>>>>>>
>>>>>>>>>>>> Adrian Crum
>>>>>>>>>>>> Sandglass Software
>>>>>>>>>>>> www.sandglass-software.com
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux
>>>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, so we need to define which are those components. So 3
>>>>>>>>>>>>>
>>>>>>>>>>>>>> points, which should be discussed separately it seems, not
>>>>>>>>>>>>>> sure of the order yet but probably this one
>>>>>>>>>>>>>> 1) Components to move to Attic. They will be freezed but still
>>>>>>>>>>>>>> available in this state in Attic (in other words slowly dying)
>>>>>>>>>>>>>> 2) Components to disable. They will be maintained, but OOTB
>>>>>>>>>>>>>> will not interfere with other components (applications or
>>>>>>>>>>>>>> other specialpurpose)
>>>>>>>>>>>>>> 3) Components to keep enabled. They must be maintained and
>>>>>>>>>>>>>> have no interactions with other components
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Components enabled and disabled must be maintained in the same
>>>>>>>>>>>>> way: it is not that a group is more important than the other.
>>>>>>>>>>>>> Also, disabling a component doesn't mean that it will not go in
>>>>>>>>>>>>> a release: we could have disabled components in releases and
>>>>>>>>>>>>> enabled components excluded from a release or vice versa.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For the point 2 we need to clarify if it could applies to
>>>>>>>>>>>>>
>>>>>>>>>>>>>> trunk also. I'd now tend to avoid differences between trunk
>>>>>>>>>>>>>> and branch releases, at the functionality or other levels.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree that the same settings should be maintained in the
>>>>>>>>>>>>> trunk and in the release branches.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move The Asset Maintenance Component To A Separate Project
Posted by Scott Gray <sc...@hotwaxmedia.com>.
OFBiz itself went through that on a much larger scale when joining the ASF.
It took some time but it wasn't a big deal.
No users are forced to do anything other than make a choice: stick with
what you have or change to what is now available. Open source users make
these types of decisions on a regular basis.
Regards
Scott
On 29 Nov 2014 14:51, "Ron Wheeler" <rw...@artifact-software.com> wrote:
> Don't forget to get ICLAs and Corporate CLAs for the new site for each
> contributor otherwise you will have trouble if you want to submit it to
> Apache OFBiz in the future.
> I guess that if you offer it under an Apache license without having an
> ICLA /CCLA in place, you would be personally liable for any claim by
> contributors in the future.
>
> Not sure that you can/should force any existing users to move to the new
> project.
> Perhaps no one is using it so #5 is not a problem but I am not sure how
> you can reach all of the people who have downloaded it.
>
> Ron
>
> On 28/11/2014 7:54 PM, Scott Gray wrote:
>
>> Hi Adrian,
>>
>> Sounds like a good plan to me. I think there should probably be some sort
>> of a delay in step #5 and it should ultimately be decided by a PMC vote at
>> that point in time as well. I totally support the concept though.
>>
>> Regards
>> Scott
>>
>> On Sat, Nov 29, 2014 at 5:20 AM, Adrian Crum <
>> adrian.crum@sandglass-software.com> wrote:
>>
>> As has been discussed in this thread, we can spin off special purpose
>>> components to their own projects - where they can form their own
>>> communities and support structure.
>>>
>>> I am willing to use the Asset Maintenance component as a trial run. Here
>>> are some of my initial thoughts, comments are welcome:
>>>
>>> 1. Check with the ASF legal department before doing anything.
>>> 2. Create a project on a popular hosting site (like SourceForge, but it
>>> could be anywhere).
>>> 3. Set up initial committers.
>>> 4. Notify the OFBiz mailing lists about the new project.
>>> 5. Drop the Asset Maintenance component from the ASF repo.
>>>
>>> The component would maintain the ASL 2 license. Support for various
>>> versions of OFBiz will be decided by the Asset Maintenance community.
>>>
>>> If the spin-off is a success, then all is good. If it fails, then the
>>> Asset Maintenance component is added back to the ASF repo.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 11/28/2014 4:01 PM, Ron Wheeler wrote:
>>>
>>> The components not supported as part of the core and framework would not
>>>> leave Apache.
>>>> They become separate sub-projects under OFBiz so that they stay in the
>>>> community but are released and supported separately so that there is
>>>> more transparency about their state.
>>>> The release of new core and framework versions gets easier.
>>>>
>>>> The implied warranties get clearer and the sub-communities supporting
>>>> each of the non-core components are :
>>>> -easier to identify
>>>> - free to set their own roadmaps based on the needs and the resources
>>>> - easier to join since you only need to learn a small set of code in
>>>> order to contribute
>>>> - do not affect the core and framework code, roadmap or release plans
>>>> except when they request extensions to the core or framework through
>>>> JIRA issues.
>>>>
>>>> The core and framework team will not have to worry about the side
>>>> components unless they belong to the sub-project and can release with a
>>>> full warranty.
>>>>
>>>> Ron
>>>>
>>>>
>>>> On 28/11/2014 10:30 AM, gil portenseigne wrote:
>>>>
>>>> First I might be a bit confuse in this email, sorry for that, quite
>>>>> ideas came up while writing it, some organization missing.
>>>>>
>>>>> Le 28/11/2014 14:31, Ron Wheeler a écrit :
>>>>>
>>>>> What is the downside if the non-core components are released on their
>>>>>> own with a clear set of documentation that describes the state of the
>>>>>> component?
>>>>>>
>>>>>> I guess there is none at first glance, it's quite the same idea :
>>>>> - A big release with core components active, and non-core component
>>>>> unactive (with included documentations)
>>>>> A monolythique one, all-included...
>>>>>
>>>>> - A Core release, first with then optional non-core component releases
>>>>> with their own documentations
>>>>> A core with packages. Less heavy but more actions... not a problem
>>>>>
>>>>> The things that make me wonder, and that's we try to achieve for
>>>>> several years with an extension management tool, are all the deviance
>>>>> possible without the control of such an Apache project.
>>>>>
>>>>> It is Out of Apache ! The component community can build their own
>>>>> component at the speed they need (often dependant on a personal
>>>>> project), without the quality control. It's good for this side
>>>>> community, we are already doing that in our way. But can lead to a
>>>>> branch component, which can't be contributed anymore to OFBiz if
>>>>> needed (for any reasons I guess).
>>>>>
>>>>> Why not stick with Apache OFBiz in contributing more, into
>>>>> desactivated non-core component using the side community advancement,
>>>>> and managing to level up these non-core quality too make them stable
>>>>> and reliable into Apache OFBiz.
>>>>>
>>>>> Specifics devs that can't be contributed into OFBiz, will remain as
>>>>> extension into the side community.
>>>>>
>>>>> If side community meets some deviance in his evolution, not following
>>>>> Apache OFBiz way, it must not have consequences like removing these
>>>>> non-core component from trunk or branches.
>>>>>
>>>>> That's why i like the idea to have in Apache OFBiz, release with
>>>>> unactive components (which can always be used and follow the Ofbiz
>>>>> way), and then everyone have the opportunity to offer other community
>>>>> components to replace unactive one, or to add to the core.
>>>>>
>>>>> Then some questions remains :
>>>>> - How can user be informed of such side communities from the OFBiz
>>>>> official site ? Is that possible ?
>>>>> - We tried to introduce a new tool to manage extension (which could be
>>>>> a solution for the first question, becoming a tool of indexation ) to
>>>>> serve this kind of purpose, but their wasn't much reactions to it. Cf
>>>>> : http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
>>>>>
>>>>>
>>>>> Gil
>>>>>
>>>>>
>>>>> My feeling is that it is better to release a clean core and framework
>>>>>> where ALL component are "warranteed" by the team to be tested and
>>>>>> supported.
>>>>>> Components that are not part of the core would be released on their
>>>>>> own with the warranty and support specified on an individual basis.
>>>>>>
>>>>>> At least the user community would know where it stands if it depends
>>>>>> a non-core component to run their business.
>>>>>>
>>>>>> I think this is preferable than releasing a big conglomeration of
>>>>>> working and non-working software that the user has to sort through to
>>>>>> figure out if they can make a usable OFBiz.
>>>>>>
>>>>>> It also simplifies the release process for the core and framework.
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>> On 28/11/2014 7:18 AM, gil portenseigne wrote:
>>>>>>
>>>>>> Hello all !
>>>>>>>
>>>>>>> I followed the discussion, a bit late :
>>>>>>>
>>>>>>> Le 28/11/2014 11:24, Jacques Le Roux a écrit :
>>>>>>>
>>>>>>> Afterthought: we agreed about having the same setting in both the
>>>>>>>> releases branches and the trunk. So if we disable a component in
>>>>>>>> the releases branches it will be also in the trunk.
>>>>>>>> Then, even we enable tests, we will not be aware of UI related
>>>>>>>> issues and globally all those which are no covered by tests. Apart
>>>>>>>> if an users enable the component and report issues.
>>>>>>>>
>>>>>>>> This might be a compromise, but we need our users to be aware of.
>>>>>>>> So they will need to be warned in the download page IMO.
>>>>>>>>
>>>>>>>> I think it's a good compromise, warning is needed to ensure that
>>>>>>>>
>>>>>>> user is aware or possible disfunctionment within these components.
>>>>>>> No tricks needed anymore to import components from trunk. Good
>>>>>>> enough for me.
>>>>>>>
>>>>>>> My opinion is that OOTB functionnalities are usable but rarely
>>>>>>> sufficient for End-User, advanced skills are needed in each project
>>>>>>> to make OFBiz fit the needs. So i guess there is no harm to let
>>>>>>> inactive (uncomplete or so) component at disposal for user who might
>>>>>>> need them.
>>>>>>>
>>>>>>> Also if you remember this thread started with my idea of creating a
>>>>>>>> wiki page to explain to our users the alternative strategy of using
>>>>>>>> release branches rather than released packages.
>>>>>>>> I'd like to have a direct link to this wiki page from the download
>>>>>>>> page. This link name could be simply "alternative strategy". What
>>>>>>>> do you think?
>>>>>>>>
>>>>>>>> Using the same method, i like the idea.
>>>>>>>
>>>>>>> Gil
>>>>>>>
>>>>>>> I will stop this thread here and will create a new thread to
>>>>>>>> discuss the modality of putting back the specialpurpose components
>>>>>>>> in the R13.07 branch.
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 27/11/2014 23:38, Jacques Le Roux a écrit :
>>>>>>>>
>>>>>>>> That sounds like a good enough solution to me
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> Le 27/11/2014 19:41, Jacopo Cappellato a écrit :
>>>>>>>>>
>>>>>>>>> This is a good point. We could find a way to programmatically
>>>>>>>>>> enable/disable the components just for the test run:
>>>>>>>>>>
>>>>>>>>>> ./ant -Denable-all=true clean-all load-demo run-tests
>>>>>>>>>>
>>>>>>>>>> but this is just an idea; we could figure out the best way to go.
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Nov 27, 2014, at 7:14 PM, Adrian Crum
>>>>>>>>>> <ad...@sandglass-software.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Be aware that disabling a component does two things:
>>>>>>>>>>
>>>>>>>>>>> 1. Speeds up unit tests because the disabled component is
>>>>>>>>>>> excluded from them.
>>>>>>>>>>> 2. Increases the chance of regressions because the disabled
>>>>>>>>>>> component is not being tested.
>>>>>>>>>>>
>>>>>>>>>>> Adrian Crum
>>>>>>>>>>> Sandglass Software
>>>>>>>>>>> www.sandglass-software.com
>>>>>>>>>>>
>>>>>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux
>>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, so we need to define which are those components. So 3
>>>>>>>>>>>>
>>>>>>>>>>>>> points, which should be discussed separately it seems, not
>>>>>>>>>>>>> sure of the order yet but probably this one
>>>>>>>>>>>>> 1) Components to move to Attic. They will be freezed but still
>>>>>>>>>>>>> available in this state in Attic (in other words slowly dying)
>>>>>>>>>>>>> 2) Components to disable. They will be maintained, but OOTB
>>>>>>>>>>>>> will not interfere with other components (applications or
>>>>>>>>>>>>> other specialpurpose)
>>>>>>>>>>>>> 3) Components to keep enabled. They must be maintained and
>>>>>>>>>>>>> have no interactions with other components
>>>>>>>>>>>>>
>>>>>>>>>>>>> Components enabled and disabled must be maintained in the same
>>>>>>>>>>>> way: it is not that a group is more important than the other.
>>>>>>>>>>>> Also, disabling a component doesn't mean that it will not go in
>>>>>>>>>>>> a release: we could have disabled components in releases and
>>>>>>>>>>>> enabled components excluded from a release or vice versa.
>>>>>>>>>>>>
>>>>>>>>>>>> For the point 2 we need to clarify if it could applies to
>>>>>>>>>>>>
>>>>>>>>>>>>> trunk also. I'd now tend to avoid differences between trunk
>>>>>>>>>>>>> and branch releases, at the functionality or other levels.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I agree that the same settings should be maintained in the
>>>>>>>>>>>> trunk and in the release branches.
>>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Re: Move The Asset Maintenance Component To A Separate Project
Posted by Ron Wheeler <rw...@artifact-software.com>.
Don't forget to get ICLAs and Corporate CLAs for the new site for each
contributor otherwise you will have trouble if you want to submit it to
Apache OFBiz in the future.
I guess that if you offer it under an Apache license without having an
ICLA /CCLA in place, you would be personally liable for any claim by
contributors in the future.
Not sure that you can/should force any existing users to move to the new
project.
Perhaps no one is using it so #5 is not a problem but I am not sure how
you can reach all of the people who have downloaded it.
Ron
On 28/11/2014 7:54 PM, Scott Gray wrote:
> Hi Adrian,
>
> Sounds like a good plan to me. I think there should probably be some sort
> of a delay in step #5 and it should ultimately be decided by a PMC vote at
> that point in time as well. I totally support the concept though.
>
> Regards
> Scott
>
> On Sat, Nov 29, 2014 at 5:20 AM, Adrian Crum <
> adrian.crum@sandglass-software.com> wrote:
>
>> As has been discussed in this thread, we can spin off special purpose
>> components to their own projects - where they can form their own
>> communities and support structure.
>>
>> I am willing to use the Asset Maintenance component as a trial run. Here
>> are some of my initial thoughts, comments are welcome:
>>
>> 1. Check with the ASF legal department before doing anything.
>> 2. Create a project on a popular hosting site (like SourceForge, but it
>> could be anywhere).
>> 3. Set up initial committers.
>> 4. Notify the OFBiz mailing lists about the new project.
>> 5. Drop the Asset Maintenance component from the ASF repo.
>>
>> The component would maintain the ASL 2 license. Support for various
>> versions of OFBiz will be decided by the Asset Maintenance community.
>>
>> If the spin-off is a success, then all is good. If it fails, then the
>> Asset Maintenance component is added back to the ASF repo.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 11/28/2014 4:01 PM, Ron Wheeler wrote:
>>
>>> The components not supported as part of the core and framework would not
>>> leave Apache.
>>> They become separate sub-projects under OFBiz so that they stay in the
>>> community but are released and supported separately so that there is
>>> more transparency about their state.
>>> The release of new core and framework versions gets easier.
>>>
>>> The implied warranties get clearer and the sub-communities supporting
>>> each of the non-core components are :
>>> -easier to identify
>>> - free to set their own roadmaps based on the needs and the resources
>>> - easier to join since you only need to learn a small set of code in
>>> order to contribute
>>> - do not affect the core and framework code, roadmap or release plans
>>> except when they request extensions to the core or framework through
>>> JIRA issues.
>>>
>>> The core and framework team will not have to worry about the side
>>> components unless they belong to the sub-project and can release with a
>>> full warranty.
>>>
>>> Ron
>>>
>>>
>>> On 28/11/2014 10:30 AM, gil portenseigne wrote:
>>>
>>>> First I might be a bit confuse in this email, sorry for that, quite
>>>> ideas came up while writing it, some organization missing.
>>>>
>>>> Le 28/11/2014 14:31, Ron Wheeler a écrit :
>>>>
>>>>> What is the downside if the non-core components are released on their
>>>>> own with a clear set of documentation that describes the state of the
>>>>> component?
>>>>>
>>>> I guess there is none at first glance, it's quite the same idea :
>>>> - A big release with core components active, and non-core component
>>>> unactive (with included documentations)
>>>> A monolythique one, all-included...
>>>>
>>>> - A Core release, first with then optional non-core component releases
>>>> with their own documentations
>>>> A core with packages. Less heavy but more actions... not a problem
>>>>
>>>> The things that make me wonder, and that's we try to achieve for
>>>> several years with an extension management tool, are all the deviance
>>>> possible without the control of such an Apache project.
>>>>
>>>> It is Out of Apache ! The component community can build their own
>>>> component at the speed they need (often dependant on a personal
>>>> project), without the quality control. It's good for this side
>>>> community, we are already doing that in our way. But can lead to a
>>>> branch component, which can't be contributed anymore to OFBiz if
>>>> needed (for any reasons I guess).
>>>>
>>>> Why not stick with Apache OFBiz in contributing more, into
>>>> desactivated non-core component using the side community advancement,
>>>> and managing to level up these non-core quality too make them stable
>>>> and reliable into Apache OFBiz.
>>>>
>>>> Specifics devs that can't be contributed into OFBiz, will remain as
>>>> extension into the side community.
>>>>
>>>> If side community meets some deviance in his evolution, not following
>>>> Apache OFBiz way, it must not have consequences like removing these
>>>> non-core component from trunk or branches.
>>>>
>>>> That's why i like the idea to have in Apache OFBiz, release with
>>>> unactive components (which can always be used and follow the Ofbiz
>>>> way), and then everyone have the opportunity to offer other community
>>>> components to replace unactive one, or to add to the core.
>>>>
>>>> Then some questions remains :
>>>> - How can user be informed of such side communities from the OFBiz
>>>> official site ? Is that possible ?
>>>> - We tried to introduce a new tool to manage extension (which could be
>>>> a solution for the first question, becoming a tool of indexation ) to
>>>> serve this kind of purpose, but their wasn't much reactions to it. Cf
>>>> : http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
>>>>
>>>>
>>>> Gil
>>>>
>>>>
>>>>> My feeling is that it is better to release a clean core and framework
>>>>> where ALL component are "warranteed" by the team to be tested and
>>>>> supported.
>>>>> Components that are not part of the core would be released on their
>>>>> own with the warranty and support specified on an individual basis.
>>>>>
>>>>> At least the user community would know where it stands if it depends
>>>>> a non-core component to run their business.
>>>>>
>>>>> I think this is preferable than releasing a big conglomeration of
>>>>> working and non-working software that the user has to sort through to
>>>>> figure out if they can make a usable OFBiz.
>>>>>
>>>>> It also simplifies the release process for the core and framework.
>>>>>
>>>>> Ron
>>>>>
>>>>> On 28/11/2014 7:18 AM, gil portenseigne wrote:
>>>>>
>>>>>> Hello all !
>>>>>>
>>>>>> I followed the discussion, a bit late :
>>>>>>
>>>>>> Le 28/11/2014 11:24, Jacques Le Roux a écrit :
>>>>>>
>>>>>>> Afterthought: we agreed about having the same setting in both the
>>>>>>> releases branches and the trunk. So if we disable a component in
>>>>>>> the releases branches it will be also in the trunk.
>>>>>>> Then, even we enable tests, we will not be aware of UI related
>>>>>>> issues and globally all those which are no covered by tests. Apart
>>>>>>> if an users enable the component and report issues.
>>>>>>>
>>>>>>> This might be a compromise, but we need our users to be aware of.
>>>>>>> So they will need to be warned in the download page IMO.
>>>>>>>
>>>>>>> I think it's a good compromise, warning is needed to ensure that
>>>>>> user is aware or possible disfunctionment within these components.
>>>>>> No tricks needed anymore to import components from trunk. Good
>>>>>> enough for me.
>>>>>>
>>>>>> My opinion is that OOTB functionnalities are usable but rarely
>>>>>> sufficient for End-User, advanced skills are needed in each project
>>>>>> to make OFBiz fit the needs. So i guess there is no harm to let
>>>>>> inactive (uncomplete or so) component at disposal for user who might
>>>>>> need them.
>>>>>>
>>>>>>> Also if you remember this thread started with my idea of creating a
>>>>>>> wiki page to explain to our users the alternative strategy of using
>>>>>>> release branches rather than released packages.
>>>>>>> I'd like to have a direct link to this wiki page from the download
>>>>>>> page. This link name could be simply "alternative strategy". What
>>>>>>> do you think?
>>>>>>>
>>>>>> Using the same method, i like the idea.
>>>>>>
>>>>>> Gil
>>>>>>
>>>>>>> I will stop this thread here and will create a new thread to
>>>>>>> discuss the modality of putting back the specialpurpose components
>>>>>>> in the R13.07 branch.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 27/11/2014 23:38, Jacques Le Roux a écrit :
>>>>>>>
>>>>>>>> That sounds like a good enough solution to me
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> Le 27/11/2014 19:41, Jacopo Cappellato a écrit :
>>>>>>>>
>>>>>>>>> This is a good point. We could find a way to programmatically
>>>>>>>>> enable/disable the components just for the test run:
>>>>>>>>>
>>>>>>>>> ./ant -Denable-all=true clean-all load-demo run-tests
>>>>>>>>>
>>>>>>>>> but this is just an idea; we could figure out the best way to go.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 27, 2014, at 7:14 PM, Adrian Crum
>>>>>>>>> <ad...@sandglass-software.com> wrote:
>>>>>>>>>
>>>>>>>>> Be aware that disabling a component does two things:
>>>>>>>>>> 1. Speeds up unit tests because the disabled component is
>>>>>>>>>> excluded from them.
>>>>>>>>>> 2. Increases the chance of regressions because the disabled
>>>>>>>>>> component is not being tested.
>>>>>>>>>>
>>>>>>>>>> Adrian Crum
>>>>>>>>>> Sandglass Software
>>>>>>>>>> www.sandglass-software.com
>>>>>>>>>>
>>>>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
>>>>>>>>>>
>>>>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux
>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Yes, so we need to define which are those components. So 3
>>>>>>>>>>>> points, which should be discussed separately it seems, not
>>>>>>>>>>>> sure of the order yet but probably this one
>>>>>>>>>>>> 1) Components to move to Attic. They will be freezed but still
>>>>>>>>>>>> available in this state in Attic (in other words slowly dying)
>>>>>>>>>>>> 2) Components to disable. They will be maintained, but OOTB
>>>>>>>>>>>> will not interfere with other components (applications or
>>>>>>>>>>>> other specialpurpose)
>>>>>>>>>>>> 3) Components to keep enabled. They must be maintained and
>>>>>>>>>>>> have no interactions with other components
>>>>>>>>>>>>
>>>>>>>>>>> Components enabled and disabled must be maintained in the same
>>>>>>>>>>> way: it is not that a group is more important than the other.
>>>>>>>>>>> Also, disabling a component doesn't mean that it will not go in
>>>>>>>>>>> a release: we could have disabled components in releases and
>>>>>>>>>>> enabled components excluded from a release or vice versa.
>>>>>>>>>>>
>>>>>>>>>>> For the point 2 we need to clarify if it could applies to
>>>>>>>>>>>> trunk also. I'd now tend to avoid differences between trunk
>>>>>>>>>>>> and branch releases, at the functionality or other levels.
>>>>>>>>>>>>
>>>>>>>>>>> I agree that the same settings should be maintained in the
>>>>>>>>>>> trunk and in the release branches.
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move The Asset Maintenance Component To A Separate Project (was:
Suggest branch rather than release strategy?)
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Hi Adrian,
Sounds like a good plan to me. I think there should probably be some sort
of a delay in step #5 and it should ultimately be decided by a PMC vote at
that point in time as well. I totally support the concept though.
Regards
Scott
On Sat, Nov 29, 2014 at 5:20 AM, Adrian Crum <
adrian.crum@sandglass-software.com> wrote:
> As has been discussed in this thread, we can spin off special purpose
> components to their own projects - where they can form their own
> communities and support structure.
>
> I am willing to use the Asset Maintenance component as a trial run. Here
> are some of my initial thoughts, comments are welcome:
>
> 1. Check with the ASF legal department before doing anything.
> 2. Create a project on a popular hosting site (like SourceForge, but it
> could be anywhere).
> 3. Set up initial committers.
> 4. Notify the OFBiz mailing lists about the new project.
> 5. Drop the Asset Maintenance component from the ASF repo.
>
> The component would maintain the ASL 2 license. Support for various
> versions of OFBiz will be decided by the Asset Maintenance community.
>
> If the spin-off is a success, then all is good. If it fails, then the
> Asset Maintenance component is added back to the ASF repo.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 11/28/2014 4:01 PM, Ron Wheeler wrote:
>
>> The components not supported as part of the core and framework would not
>> leave Apache.
>> They become separate sub-projects under OFBiz so that they stay in the
>> community but are released and supported separately so that there is
>> more transparency about their state.
>> The release of new core and framework versions gets easier.
>>
>> The implied warranties get clearer and the sub-communities supporting
>> each of the non-core components are :
>> -easier to identify
>> - free to set their own roadmaps based on the needs and the resources
>> - easier to join since you only need to learn a small set of code in
>> order to contribute
>> - do not affect the core and framework code, roadmap or release plans
>> except when they request extensions to the core or framework through
>> JIRA issues.
>>
>> The core and framework team will not have to worry about the side
>> components unless they belong to the sub-project and can release with a
>> full warranty.
>>
>> Ron
>>
>>
>> On 28/11/2014 10:30 AM, gil portenseigne wrote:
>>
>>> First I might be a bit confuse in this email, sorry for that, quite
>>> ideas came up while writing it, some organization missing.
>>>
>>> Le 28/11/2014 14:31, Ron Wheeler a écrit :
>>>
>>>> What is the downside if the non-core components are released on their
>>>> own with a clear set of documentation that describes the state of the
>>>> component?
>>>>
>>> I guess there is none at first glance, it's quite the same idea :
>>> - A big release with core components active, and non-core component
>>> unactive (with included documentations)
>>> A monolythique one, all-included...
>>>
>>> - A Core release, first with then optional non-core component releases
>>> with their own documentations
>>> A core with packages. Less heavy but more actions... not a problem
>>>
>>> The things that make me wonder, and that's we try to achieve for
>>> several years with an extension management tool, are all the deviance
>>> possible without the control of such an Apache project.
>>>
>>> It is Out of Apache ! The component community can build their own
>>> component at the speed they need (often dependant on a personal
>>> project), without the quality control. It's good for this side
>>> community, we are already doing that in our way. But can lead to a
>>> branch component, which can't be contributed anymore to OFBiz if
>>> needed (for any reasons I guess).
>>>
>>> Why not stick with Apache OFBiz in contributing more, into
>>> desactivated non-core component using the side community advancement,
>>> and managing to level up these non-core quality too make them stable
>>> and reliable into Apache OFBiz.
>>>
>>> Specifics devs that can't be contributed into OFBiz, will remain as
>>> extension into the side community.
>>>
>>> If side community meets some deviance in his evolution, not following
>>> Apache OFBiz way, it must not have consequences like removing these
>>> non-core component from trunk or branches.
>>>
>>> That's why i like the idea to have in Apache OFBiz, release with
>>> unactive components (which can always be used and follow the Ofbiz
>>> way), and then everyone have the opportunity to offer other community
>>> components to replace unactive one, or to add to the core.
>>>
>>> Then some questions remains :
>>> - How can user be informed of such side communities from the OFBiz
>>> official site ? Is that possible ?
>>> - We tried to introduce a new tool to manage extension (which could be
>>> a solution for the first question, becoming a tool of indexation ) to
>>> serve this kind of purpose, but their wasn't much reactions to it. Cf
>>> : http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
>>>
>>>
>>> Gil
>>>
>>>
>>>> My feeling is that it is better to release a clean core and framework
>>>> where ALL component are "warranteed" by the team to be tested and
>>>> supported.
>>>> Components that are not part of the core would be released on their
>>>> own with the warranty and support specified on an individual basis.
>>>>
>>>> At least the user community would know where it stands if it depends
>>>> a non-core component to run their business.
>>>>
>>>> I think this is preferable than releasing a big conglomeration of
>>>> working and non-working software that the user has to sort through to
>>>> figure out if they can make a usable OFBiz.
>>>>
>>>> It also simplifies the release process for the core and framework.
>>>>
>>>> Ron
>>>>
>>>> On 28/11/2014 7:18 AM, gil portenseigne wrote:
>>>>
>>>>> Hello all !
>>>>>
>>>>> I followed the discussion, a bit late :
>>>>>
>>>>> Le 28/11/2014 11:24, Jacques Le Roux a écrit :
>>>>>
>>>>>> Afterthought: we agreed about having the same setting in both the
>>>>>> releases branches and the trunk. So if we disable a component in
>>>>>> the releases branches it will be also in the trunk.
>>>>>> Then, even we enable tests, we will not be aware of UI related
>>>>>> issues and globally all those which are no covered by tests. Apart
>>>>>> if an users enable the component and report issues.
>>>>>>
>>>>>> This might be a compromise, but we need our users to be aware of.
>>>>>> So they will need to be warned in the download page IMO.
>>>>>>
>>>>>> I think it's a good compromise, warning is needed to ensure that
>>>>> user is aware or possible disfunctionment within these components.
>>>>> No tricks needed anymore to import components from trunk. Good
>>>>> enough for me.
>>>>>
>>>>> My opinion is that OOTB functionnalities are usable but rarely
>>>>> sufficient for End-User, advanced skills are needed in each project
>>>>> to make OFBiz fit the needs. So i guess there is no harm to let
>>>>> inactive (uncomplete or so) component at disposal for user who might
>>>>> need them.
>>>>>
>>>>>> Also if you remember this thread started with my idea of creating a
>>>>>> wiki page to explain to our users the alternative strategy of using
>>>>>> release branches rather than released packages.
>>>>>> I'd like to have a direct link to this wiki page from the download
>>>>>> page. This link name could be simply "alternative strategy". What
>>>>>> do you think?
>>>>>>
>>>>> Using the same method, i like the idea.
>>>>>
>>>>> Gil
>>>>>
>>>>>>
>>>>>> I will stop this thread here and will create a new thread to
>>>>>> discuss the modality of putting back the specialpurpose components
>>>>>> in the R13.07 branch.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 27/11/2014 23:38, Jacques Le Roux a écrit :
>>>>>>
>>>>>>> That sounds like a good enough solution to me
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 27/11/2014 19:41, Jacopo Cappellato a écrit :
>>>>>>>
>>>>>>>> This is a good point. We could find a way to programmatically
>>>>>>>> enable/disable the components just for the test run:
>>>>>>>>
>>>>>>>> ./ant -Denable-all=true clean-all load-demo run-tests
>>>>>>>>
>>>>>>>> but this is just an idea; we could figure out the best way to go.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 27, 2014, at 7:14 PM, Adrian Crum
>>>>>>>> <ad...@sandglass-software.com> wrote:
>>>>>>>>
>>>>>>>> Be aware that disabling a component does two things:
>>>>>>>>>
>>>>>>>>> 1. Speeds up unit tests because the disabled component is
>>>>>>>>> excluded from them.
>>>>>>>>> 2. Increases the chance of regressions because the disabled
>>>>>>>>> component is not being tested.
>>>>>>>>>
>>>>>>>>> Adrian Crum
>>>>>>>>> Sandglass Software
>>>>>>>>> www.sandglass-software.com
>>>>>>>>>
>>>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
>>>>>>>>>
>>>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux
>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Yes, so we need to define which are those components. So 3
>>>>>>>>>>> points, which should be discussed separately it seems, not
>>>>>>>>>>> sure of the order yet but probably this one
>>>>>>>>>>> 1) Components to move to Attic. They will be freezed but still
>>>>>>>>>>> available in this state in Attic (in other words slowly dying)
>>>>>>>>>>> 2) Components to disable. They will be maintained, but OOTB
>>>>>>>>>>> will not interfere with other components (applications or
>>>>>>>>>>> other specialpurpose)
>>>>>>>>>>> 3) Components to keep enabled. They must be maintained and
>>>>>>>>>>> have no interactions with other components
>>>>>>>>>>>
>>>>>>>>>> Components enabled and disabled must be maintained in the same
>>>>>>>>>> way: it is not that a group is more important than the other.
>>>>>>>>>> Also, disabling a component doesn't mean that it will not go in
>>>>>>>>>> a release: we could have disabled components in releases and
>>>>>>>>>> enabled components excluded from a release or vice versa.
>>>>>>>>>>
>>>>>>>>>> For the point 2 we need to clarify if it could applies to
>>>>>>>>>>> trunk also. I'd now tend to avoid differences between trunk
>>>>>>>>>>> and branch releases, at the functionality or other levels.
>>>>>>>>>>>
>>>>>>>>>> I agree that the same settings should be maintained in the
>>>>>>>>>> trunk and in the release branches.
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>