incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Wallis <>
Subject RE: [ATTN MENTOR] Re: DISCUSS: Ripple as a sub-project of Cordova
Date Thu, 26 Jul 2012 17:51:15 GMT
I would prefer that we have a pretty good idea of what the final resting place should be and
work towards that right away.  While it probably is fairly "easy" on the Apache side to promote
a sub-project into a top-level one, it could cause headaches for any downstream consumers
of the project if it would involve repository moves, renaming, what-have-you. If the move
could be fairly transparent then I don't have an issue on this front. ;)

In general though, I agree that the biggest question will be one of community.  From where
things stand, Ripple will not be solely tied to Cordova, it will have other uses.  With the
importance that the Cordova community is putting on Ripple, I have the feeling that there
will be enough interconnections to help foster a strong enough community around Ripple as
a top-level project. (I hope) there will be shared committers, Cordova consumption of the
Ripple project, continued joint ventures in terms of community out-reach and involvement,
Cordova community shared learnings on becoming an Apache project and navigating the process,
etc.  I see the community aspect as a risk if Ripple were to be a top-level project, but with
the Cordova community support, I think it will be a small one.


Ken Wallis

Product Manager – BlackBerry WebWorks

Research In Motion

(905) 629-4746 x14369

From: Filip Maj []
Sent: Thursday, July 26, 2012 1:07 PM
Subject: Re: [ATTN MENTOR] Re: DISCUSS: Ripple as a sub-project of Cordova

In my mind the core issue is about community, not about development.

With that in mind, and taking Ross' point below, I think it makes sense to
have it as a stand-alone project.

However, with respect to Jukka's question about development _of_ Ripple,
there is certainly an overlap and integration between Cordova and Ripple
development. Gord and I have talked about how, when a new platform makes
its way into Cordova and has the start of a full implementation, the first
step would be to take the platform's JavaScript implementation and run the
Cordova test suite inside of Ripple (before even going to the platform's
emulator / device). This is already in a way exhibited by Tizen
essentially using Ripple as their simulator in the first place.

So in conclusion: both are viable paths IMO, and we do not get to a
conclusion haha.

What about the idea of introducing Ripple into Cordova for the start, and
then later splitting it out? Seems like then we could kick-start Ripple's
exposure and community/committer interaction by leveraging what Cordova
already has. If that sounds acceptable, then my question would be, at what
point does it make sense to put Ripple into its own top-level project?

On 7/26/12 7:53 AM, "Ross Gardler" <> wrote:

>+1 to everything Jukka said below.
>Another way of looking at it is "will the Ripple community be a
>sub-set of the Cordova community", if yes then sub-project is probably
>best. If not, i.e. there will be members of the Ripple community who
>are not also members of the Cordova community, then it probably ought
>to be a separate project to maximise its visibility as a separate
>On 26 July 2012 15:25, Jukka Zitting <> wrote:
>> Hi,
>> On Thu, Jul 26, 2012 at 4:06 PM,  <> wrote:
>>> There is a lot of overlap between the cordova and ripple communities
>>>and I was originally
>>> hoping to foster their community into ours ;)
>> I guess the main question here is whether Cordova committers will be
>> working on / looking at Ripple code and vice versa on a regular basis.
>> If that's the case (i.e. there's significant overlap in actual
>> development activity), then having the codebases in one project is a
>> good approach. weinre is a good example of such a case.
>> If not (for example if separate mailing lists are needed, etc.), then
>> it's best for both codebases to have their own projects even if
>> there's overlap on the level of individual committers.
>> The decision on this doesn't need to be final, as projects can always
>> split or merge projects later on, but starting with at least a good
>> approximation of the ultimate or ideal community/project structure
>> will of course make things much easier.
>> BR,
>> Jukka Zitting
>Ross Gardler (@rgardler)
>Programme Leader (Open Development)

This transmission (including any attachments) may contain confidential information, privileged
material (including material protected by the solicitor-client or other applicable privileges),
or constitute non-public information. Any use of this information by anyone other than the
intended recipient is prohibited. If you have received this transmission in error, please
immediately reply to the sender and delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended recipients is not authorized
and may be unlawful.

View raw message