ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Gray <scott.g...@hotwaxmedia.com>
Subject Re: Move The Asset Maintenance Component To A Separate Project
Date Sat, 29 Nov 2014 02:38:16 GMT
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.

On 29 Nov 2014 14:51, "Ron Wheeler" <rwheeler@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
>>>>>> 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
>>>>>> 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
>>>>>>>> releases branches and the trunk. So if we disable a component
>>>>>>>> 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.
>>>>>>>> if an users enable the component and report issues.
>>>>>>>> This might be a compromise, but we need our users to be aware
>>>>>>>> So they will need to be warned in the download page IMO.
>>>>>>>>   I think it's a good compromise, warning is needed to ensure
>>>>>>> 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
>>>>>>> need them.
>>>>>>>  Also if you remember this thread started with my idea of creating
>>>>>>>> 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
>>>>>>>> page. This link name could be simply "alternative strategy".
>>>>>>>> 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> 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
>>>>>>>>>>>> <jacques.le.roux@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
>>>>>>>>>>>>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message