Ross, I would love to become more familiar with the specific reasoning, when you have time to share it.
On 7/26/12 11:49 AM, "Brian LeRoux" <b...@brian.io> wrote: >I think Ripple as a stand alone is probably the best place for it >conceptually. From an infrastructure standpoint there is so much >overlap between the projects its seems inefficient so its really the >only place I'm having difficulty reconciling. If Ripple does go TLP >then it has to have all the git repo, issue tracker, wiki, website, >and mailing list ceremony that we kinda already enjoy in this space. >That said, having all that stuff decoupled is also not a bad thing at >all. > >Ultimately, I'm very happy to see the code joining us at Apache and >whatever choice the RIM creators/committers/contributors decide we >support! > > >On Thu, Jul 26, 2012 at 11:36 AM, Ross Gardler ><rgard...@opendirective.com> wrote: >> Whilst Cordova can see idle in any light or likes, from the ASF >>perspective >> it is just a project. The ASF is the umbrella organisation and it >>resists >> the idea of projects becoming umbrellas. There are good, community >>focused >> reasons for this. Reasons that come from practical experiences within >>this >> foundation. Unfortunately I'm on a mobile so providing references right >>now >> is hard. >> >> I'm happy to explore this further if people want to understand it. >> >> That being said, I am not suggesting I'd object to either approach being >> discussed here. I only object to a justification that hinges on Cordova >> being an umbrella project. >> >> From a mobile device - forgive errors and terseness >> On Jul 26, 2012 7:19 PM, <gtan...@gmail.com> wrote: >> >>> I sometimes see cordova not as a specific platform (or set of APIs) >>>but as >>> a leader in the open mobile web. If we are able to step away from the >>>idea >>> of cordova being a singular platform but the bleeding edge of mobile >>>web r >>> & d it makes sense to have ripple be a part of that. >>> >>> I might be getting caught up in religious zealotry but that is kind of >>>the >>> vision I see for cordova and seeing ripple fit really well into that >>>vision. >>> >>> >>> Sent on the TELUS Mobility network with BlackBerry >>> >>> -----Original Message----- >>> From: Filip Maj <f...@adobe.com> >>> Date: Thu, 26 Jul 2012 11:13:57 >>> To: >>>callback-dev@incubator.apache.org<callback-dev@incubator.apache.org> >>> Reply-To: callback-dev@incubator.apache.org >>> Subject: Re: [ATTN MENTOR] Re: DISCUSS: Ripple as a sub-project of >>>Cordova >>> >>> You can definitely count on some of us Cordova committers (Michael >>>Brooks, >>> myself) to continue contributing to Ripple. Hopefully we can encourage >>> others in our committer community as well as abroad to do the same. >>> >>> On 7/26/12 10:51 AM, "Ken Wallis" <kwal...@rim.com> wrote: >>> >>> >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 [f...@adobe.com] >>> >Sent: Thursday, July 26, 2012 1:07 PM >>> >To: callback-dev@incubator.apache.org >>> >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" <rgard...@opendirective.com> 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 >>> >>community. >>> >> >>> >>Ross >>> >> >>> >>On 26 July 2012 15:25, Jukka Zitting <jukka.zitt...@gmail.com> wrote: >>> >>> Hi, >>> >>> >>> >>> On Thu, Jul 26, 2012 at 4:06 PM, <gtan...@gmail.com> 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) >>> >>OpenDirective http://opendirective.com >>> > >>> > >>> >--------------------------------------------------------------------- >>> >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. >>> >>>
