incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: [PROPOSAL] CeltiXfire Project
Date Wed, 05 Jul 2006 12:37:09 GMT
If the whole goal is for the 2 external projects to
"merge" and become one ASF project, then there must
be a point in time when the external ones no longer
exist. If the intent is that these 2 external projects
will continue to co-exist while the "merged" project
is also expected to grow and develop within the ASF,
then what the ASF project is is a fork, not a merge
and continuation of the old ones.

No, if someone wants to take the old codebases and
do things with them, they are perfectly fine to do
that. But if the *current communities* expect that
the codebases will continue to develop in parallel,
then I see no reason for a merged fork to enter
the incubator.

On Jun 30, 2006, at 2:21 PM, Guillaume Nodet wrote:

> Could you please explain the rational behind that ?
> When merging two existing code bases, the two community will
> certainly focus on the merge, but existing users should not be
> left without any support.  Even when the podling start
> release something, there are big changes that the new project
> will be incompatible with the old donations.
> This of course leads to the need for bug fix releases on the old
> projects.
> On another point, the old code bases are open source and when
> licensed under ASL, you have no way to control who use
> those codebases.
> Merging two projects give a third project, not something that is
> backward compatible with the old codebases...
>
> Cheers,
> Guillaume Nodet
>
> Jim Jagielski wrote:
>
>> Yes, up until the podling can make releases, the old
>> "external" projects still can do releases. However,
>> it's expected that once the podling starts releases,
>> that the 2 external ones shut down.
>>
>> On Jun 30, 2006, at 9:30 AM, Dan Diephouse wrote:
>>
>>> Hi Jim,
>>> Even once we're in the incubator the XFire project will still  
>>> have  to do releases. We have a 1.2 release in progress and will  
>>> be doing  bug fix releases as well.  Additionally, I would  
>>> imagine IONA might  want to issue a bug fix release at some point  
>>> for Celtix. I can't  really comment on them though.
>>>
>>> - Dan
>>>
>>> Jim Jagielski wrote:
>>>
>>>> We've handled these types of things before, for example
>>>> with SpamAssassin and Cayenne, when external codebases
>>>> were being folded into the incubator. What they've done
>>>> is mention on the old sites that the projects are
>>>> now ASF Incubator projects, etc... The intent is that
>>>> until the code has been relicensed to the AL 2.0, we
>>>> cannot host it here, but as soon as that happens, the
>>>> old sites no longer host the current codebases, just
>>>> the old ones.
>>>>
>>>> At no time should Celtix and XFire continue parallel
>>>> development with what is in the Incubator after the
>>>> podling has started.
>>>>
>>>> On Jun 30, 2006, at 8:01 AM, Paul Fremantle wrote:
>>>>
>>>>> Robert +1
>>>>>
>>>>> I think also, given that I understand that the Celtix and XFire
>>>>> projects will remain alive outside, at least for the initial  
>>>>> future,
>>>>> that it would help reduce confusion to have a separate and  
>>>>> distinct
>>>>> name for the Apache project.
>>>>>
>>>>> Paul
>>>>>
>>>>> On 6/30/06, robert burrell donkin   
>>>>> <robertburrelldonkin@gmail.com>  wrote:
>>>>>
>>>>>> On 6/21/06, Justin Erenkrantz <justin@erenkrantz.com> wrote:
>>>>>> >
>>>>>> > On 6/21/06, Dan Diephouse <dan@envoisolutions.com> wrote:
>>>>>> > > Currently the plan is to leave both the old websites &
 
>>>>>> docs   will at the
>>>>>> > > old locations. And XFire will be making release until 
 
>>>>>> Celtixfire
>>>>>> > > releases a .0 release. I think Celtix will probably make
  
>>>>>> some  1.x or
>>>>>> > > 1.0.x releases as well.
>>>>>> >
>>>>>> > Given that, I think it's probably prudent to consider    
>>>>>> alternative names.
>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> > Is this official policy? Or do we just need to come to  
>>>>>> some   consensus as
>>>>>> > > to whether or not this will be confusing for our users?
>>>>>> >
>>>>>> > Our naming policy is to strive very hard not to conflict  
>>>>>> with any
>>>>>> > other projects.  If those projects are going to continue   

>>>>>> independently
>>>>>> > of CeltiXfire, then I'd view that as a conflict we should  
>>>>>> avoid.
>>>>>>
>>>>>>
>>>>>> i wonder as well whether iona may need to consider whether  
>>>>>> they   really
>>>>>> understand the implications of choosing this name for the   
>>>>>> apache  project.
>>>>>> the ASF would own the Apache CeltiXFire trademark and the    
>>>>>> community is very
>>>>>> sensitive to issues around usage especially with regard to   
>>>>>> marketing.
>>>>>>
>>>>>> our model is different from objectweb and it is likely that  
>>>>>> the   existing
>>>>>> approach that iona takes when marketing celtix would need to  
>>>>>> be   changed.
>>>>>> apache is really centered on individuals. corporations of  
>>>>>> all   kinds as well
>>>>>> as many individuals find space to coorporate by this focus.   
>>>>>> this  corporation
>>>>>> transparency implies neutrality. AIUI this is very different  
>>>>>> to   the approach
>>>>>> taken at (for example) objectweb.
>>>>>>
>>>>>> in addition, it is possible that iona may wish to maintain    
>>>>>> separate patched
>>>>>> versions of the apache codebase. this may cause difficulties  
>>>>>> if   iona needed
>>>>>> to promote these products using an apache trademark.
>>>>>>
>>>>>> quite a lot of energy would be required for iona to maintain    
>>>>>> marketing
>>>>>> material making extensive use of a possible Apache  
>>>>>> CeltiXFire   trademark. a
>>>>>> growing number of projects are also known to the outside by    
>>>>>> marketing names
>>>>>> (for example apache derby). this allows a much greater degree   
>>>>>> of  freedom as
>>>>>> well as building separate value for their corporation in  
>>>>>> their  brand.
>>>>>>
>>>>>> this may help to explain the trend towards unique but non-   
>>>>>> descriptive names
>>>>>> for projects.
>>>>>>
>>>>>> - robert
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Paul Fremantle
>>>>> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>>>>>
>>>>> http://bloglines.com/blog/paulfremantle
>>>>> paul@wso2.com
>>>>>
>>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>>
>>>>> ------------------------------------------------------------------ 
>>>>> -- -
>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>>
>>> -- 
>>> Dan Diephouse
>>> (616) 971-2053
>>> Envoi Solutions LLC
>>> http://netzooid.com
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message