>> So you are suggesting we are maintaining a branch to the liking of a company. >> Probably its nice, but what if other companies ask for the same?
Sorry. A temporary fork with a branch would be better, as I did not mean to suggest we maintain it. As long as they can access the commit diffs and sync as you said. :-) >> Or is it something deeper, like the build? Depending on the outcome one can >> think about what is necessary when it comes to a "plugin" system I detailed the specifics of what changed farther down in my reply, but basically, the main areas that things were changed in the BlackBerry distro were: - Extra UI modules (i.e lib/client/ui/plugins*) - Alternate (decoupled) builds (i.e. rim.chrome.extension) Also, to expand from that GitHub issue: Perhaps we don't need to define a way to have external, atomic "plugins" for Ripple (nor have them based around UI plugin architecture either). Perhaps just an ability to simply overlay custom files onto the main codebase pre-build is all we need (as has been suggested in the past by Dan, as well)? I.e. Say you have (for lack of a better word..) "ripple_plugins/lib/client/ui/plugins/foo.js" in your thirdparty fork. During Ripple's build that could somehow be detected, and replaced/created in "lib/client/ui/plugins", in a one-to-one mapping. The same could be done for the different files used in "targets/rim.chrome.extension". Anyways, a thought to mention. Not sure if it covers all use cases for extending Ripple ATM, but it could be simple. >> That said, sorry if I am approaching to naive on that - I am lacking >> the background >> of you guys and of course I might not understand the implication of >> removing RIM specific >> things fully. Feel free to educate me, if necessary. Anyone for BlackBerry please do chime in, but I don't think removing all these things will cause any regressions in the ASF codebase, nor theirs. Also, given the modularity of code in Ripple, it should not be much of a hassle to add/remove a lot (if not all) of this, either. As far as I recall, I would be specifically removing: - BlackBerry EULA - WebWorks UI to Build and Deploy apps (only works with BlackBerry distro) - Modify "About Ripple" modal (button in Settings panel) to not show version for Ripple Build & Deploy services. - Remove rim.chrome.extension build files - Remove build/scripts/build.sh (it just deploys and zips Ripple for the BlackBerry internal builds). That should be about it, I believe. On Thu, Apr 11, 2013 at 3:40 AM, Christian Grobmeier <[email protected]>wrote: > On Wed, Apr 10, 2013 at 9:11 PM, Brent Lintner <[email protected]> > wrote: > > Perhaps it might be easiest and straightforward if we (for the time > being) > > commit RIM specific things out (like the RIM chrome extension build), > then > > create a new branch with revert commits of those removals, so BlackBerry > > can easily rebase and keep their features for their releases. > > So you are suggesting we are maintaining a branch to the liking of a > company. > Probably its nice, but what if other companies ask for the same? > > What, if we would create a fork at GitHub with these reverted commits. > As I understood it there are some RIM people working on Ripple, so they > might > like to have access to that repository. They would be able to keep the > codebase > in sync themselves. > > > At some point, thought, perhaps there could be a way for external parties > > to extend the project codebase easily. For example, as suggested by Dan a > > while ago -> https://github.com/blackberry/Ripple-UI/issues/691 > > Very much +1. > > Maybe it is also worth to briefly outline what RIM people changed. I > mean, is it just UI? > Or is it something deeper, like the build? Depending on the outcome one can > think about what is necessary when it comes to a "plugin" system > > > Also, I don't mind taking this issue on, as well as removing all RIM > > specific things, if this is agreeable. :-) > > +1 > > That said, sorry if I am approaching to naive on that - I am lacking > the background > of you guys and of course I might not understand the implication of > removing RIM specific > things fully. Feel free to educate me, if necessary. > > Cheers > > > > > > > > > > On Wed, Apr 10, 2013 at 5:28 AM, Christian Grobmeier (JIRA) < > [email protected] > >> wrote: > > > >> Christian Grobmeier created RIPPLE-12: > >> ----------------------------------------- > >> > >> Summary: Discuss Future of Chrome RIM Extension > >> Key: RIPPLE-12 > >> URL: https://issues.apache.org/jira/browse/RIPPLE-12 > >> Project: Apache Ripple > >> Issue Type: Bug > >> Reporter: Christian Grobmeier > >> > >> > >> From discussion on the mailinglist, asking about the RIM Chrome > Extension: > >> > >> "The rim chrome extension is used for the > >> http://developer.blackberry.com/html5 release of Ripple, vs the Chrome > >> Store extension. It has a few extra things such as a slightly different > >> manifest.json, some different extension files to enable a UI to > >> build/deploy WebWorks applications, the ability to sign a EULA, etc. > >> > >> However now that we are in the incubator, I think stuff like that (and > >> other RIM specific things) needs to be figured out what to with (in the > >> best interests of the project as a whole). I.e should they be in an > >> external fork and not part of the main project? This is something I (or > >> some others) was hoping to start a discussion about soon. :-)" > >> (Brent Lintner) > >> > >> -- > >> This message is automatically generated by JIRA. > >> If you think it was sent incorrectly, please contact your JIRA > >> administrators > >> For more information on JIRA, see: > http://www.atlassian.com/software/jira > >> > > > > > > > > -- > > Brent > > > > -- > http://www.grobmeier.de > https://www.timeandbill.de > -- Brent
