incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Porter" <brett.por...@gmail.com>
Subject Re: [PROPOSAL] CeltiXfire Project
Date Sat, 01 Jul 2006 00:34:48 GMT
What about maintaining both as branches of the CeltiXFire project?

- Brett

On 01/07/06, Dan Diephouse <dan@envoisolutions.com> wrote:
> +1 - The XFire community will definitely still need the ability to make
> releases after we graduate. As you said, there are big incompatabile
> changes (I think of this as like a 2.0)  and its a merge, so we can't
> leave existing users in the dust.
> - Dan
>
> 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
> >
>
>
> --
> 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
>
>


-- 
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/

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


Mime
View raw message