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
<[EMAIL PROTECTED]> wrote:
On 6/21/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:
>
> On 6/21/06, Dan Diephouse <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
------------------------------------------------------------------
-- -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
