Re: Move The Asset Maintenance Component To A Separate Project

[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