Cordova for Ubuntu
Hello, I am working on Cordova port for Ubuntu Touch/Ubuntu. Currently it supports: 1. cli project managment 2. most of core plugins The code can be found here: https://launchpad.net/cordova-ubuntu/ https://github.com/Zaspire/cordova-plugman https://github.com/Zaspire/cordova-cli https://github.com/Zaspire/cordova-plugin-* What is the next steps for getting this into the apache repo's and merged in? _ Best regards, Maxim Ermilov
Re: Cordova for Ubuntu
First step is to get a CLA signed w/ Apache. [1] The next steps are to read up on how to become a committer [2] and the workflow for contribution [3] and committers [4]. I just filed an issue w/ Infra to get a new repo setup for cordova-ubuntu. [5] Not much we can do there until we have a Repo. (Sometimes bugging the Infra guys on IRC can help speed things up.) In the meantime, you can create pull requests to Plugman, CLI and Plugin* repos to our Apache mirrors for review which should be more than enough to land full commit rights. Welcome to Cordova. =) =) [1] http://www.apache.org/licenses/ [2] http://wiki.apache.org/cordova/BecomingACommitter [3] http://wiki.apache.org/cordova/ContributorWorkflow [4] http://wiki.apache.org/cordova/CommitterWorkflow [5] https://issues.apache.org/jira/browse/INFRA-6844 On Mon, Oct 7, 2013 at 12:50 AM, Maxim Ermilov maxim.ermi...@canonical.comwrote: Hello, I am working on Cordova port for Ubuntu Touch/Ubuntu. Currently it supports: 1. cli project managment 2. most of core plugins The code can be found here: https://launchpad.net/cordova-ubuntu/ https://github.com/Zaspire/cordova-plugman https://github.com/Zaspire/cordova-cli https://github.com/Zaspire/cordova-plugin-* What is the next steps for getting this into the apache repo's and merged in? _ Best regards, Maxim Ermilov
Cordova CLI pre_package hook
Hi guys, I noticed that only the WP7 parser fired a hook (with the name pre_package) on the cordova-cli master branch when updating a project, this hook is missing in the WP8 parser so I added this hook. I also noticed that the hook on the WP7 parser didn't work correctly because the hook is fired asynchronous. I patched this in the WP7 project. I already signed the CLA so I was hoping someone could take a look at my pull request! Any feedback is appreciated. https://github.com/apache/cordova-cli/pull/43 This is my first patch for Cordova so I'm not really sure what the workflow is, should I create a issue on Jira first? I hope to write some more patches, mainly for Windows Phone, Android and maybe Windows 8. Thanks for reading :) Best regards, Dick van den Brink
RE: Cordova CLI pre_package hook
I already found the steps for becoming a comitter on the mailing list (thread Cordova for Ubuntu), will read into it :) [1] http://www.apache.org/licenses/ [2] http://wiki.apache.org/cordova/BecomingACommitter [3] http://wiki.apache.org/cordova/ContributorWorkflow [4] http://wiki.apache.org/cordova/CommitterWorkflow
Re: Updating plugin code on prepare
Did this feature land in 3.1.0 or is it targeted for 3.2.0? On 2013-10-03 11:30, Michal Mocny wrote: Yeah Braden we've diverged sorry, lets focus. Big +1 for your proposal to make prepare step do what users expect. -Michal On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson bra...@chromium.orgwrote: I agree that the syncing solutions are too complex and confusing. I return, then, to my original proposal all those emails ago: updating the native plugin files in platforms/foo when you prepare, to make life easier for plugin developers. When coupled with the present cordova plugin add --link, and future cordova watch, I think this makes the plugin developer flow pretty good, and without making it too magical or harder to understand. I think it simplifies prepare: on prepare, your native projects are updated to reflect the state of plugins/ and www/. Right now, only www/, assets and js-modules get updated, but not native code. As to Xcode and symlinks and all the rest of the borderline thread hijacking, I think that regardless of what editor you use, you have to be editing the right file. Xcode and Eclipse make this harder than it needs to be, but our job is not to make them suck less. Braden On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana csantan...@gmail.com wrote: +1 Anis corodova-cli/plugman should be building block components to higher level Tools/IDE. That we can do better sure, lets provide a few examples using blog pots and maybe videos tutorials vs. trying to support every use case with code. A watch function could be as simple as using grunt-contrib-watch to a more complicated environment like rsync/Eclipse I agree lets put emphasis on documenting use cases and the correct approach. When to get the best out of using prepare, merges, and hooks All I said applies when you have the Web Developer hat. For people that have the Native Plugin Developer hat then we can do things first for cordova-contributors than others can choose to use on their own risk since it could be changing too fast and maybe too narrow use case. --Carlos --Carlos On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI anis.ka...@gmail.com wrote: I gave some thought to this problem and I think we should just leave everything as is. Here's my reasoning: - Most web developers use a text editor (vim, sublime text, text mate, notepad++, ) to edit their HTML/CSS/Javascript. I've never seen anyone use a fully fledged IDE to edit web assets. It would be like using Microsoft Word to edit a simple .TXT or .MD file - Other developers, people who write Java or Objective C, etc.. use Xcode, Eclipse, IntelliJ, ...and I think these people are not good candidates for cordova-cli. The original PhoneGap promise (now Apache Cordova) was to make it easy for Web Developers to write Mobile Apps using web technologies and I believe that promise is fulfilled with cordova-cli. You have a folder where you drop in your web assets and you can build/deploy to a device or simulate. If people want to use an IDE, then they should be creating native projects with our create scripts and use plugman to manage their plugins. Our documentation should point our users to the right approach depending on the use case. For example: - Building for only one platform ? Building a hybrid app ? Want to use an IDE (Eclipse, Xcode) ? You should use the create scripts and plugman to manage plugins - Building a cross-platform app ? Like managing your project from the command-line ? Want to use your favo(u)rite text editor ? Use cordova-cli These double symlinking, backsyncing solutions will be a source of confusion and issues in my humble opinion. I've said it before but sometimes by trying to please everyone you end up pleasing no one. my .02c -a On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny mmo...@chromium.org wrote: On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve agri...@chromium.org wrote: Just tried some symlinks in Xcode 5: - Copying assets work (due to our custom build step) - Building works (compiler follows links just fine) - Editing a fail (big fail. Files open but changes cannot be saved.) Hmm, changes via xcode to symlinks fail, you mean? That would be hard to fix, but perhaps at least its feedback to the user not to make direct edits there, when using CLI workflow ;) so may still be a valid change to make. For Xcode though, it is an option to change our installation step to have Xcode reference the native files within plugins/ rather than within platforms/. Symlinks in Eclipse: - Copying assets works out-of-the-box - Build works fine - Editing seems to work fine (edits saved to symlinked location). Still though, maybe the best solution would be a combination of the two? Have prepare know when an remove+add is necessary? Yes, I think thats what we are suggesting. The original email mentioned prepare knowing when remove+add are necessary, which I think is already settled as a good idea. Not
Re: Cordova CLI pre_package hook
I've added some comments. Ping this thread when you have a CLA on file and have made those changes, and I'll pull this change. Braden On Mon, Oct 7, 2013 at 10:17 AM, Dick Van den Brink d_vandenbr...@outlook.com wrote: Hi guys, I noticed that only the WP7 parser fired a hook (with the name pre_package) on the cordova-cli master branch when updating a project, this hook is missing in the WP8 parser so I added this hook. I also noticed that the hook on the WP7 parser didn't work correctly because the hook is fired asynchronous. I patched this in the WP7 project. I already signed the CLA so I was hoping someone could take a look at my pull request! Any feedback is appreciated. https://github.com/apache/cordova-cli/pull/43 This is my first patch for Cordova so I'm not really sure what the workflow is, should I create a issue on Jira first? I hope to write some more patches, mainly for Windows Phone, Android and maybe Windows 8. Thanks for reading :) Best regards, Dick van den Brink
Re: Updating plugin code on prepare
This feature has not received any work yet, largely because I was away most of last week. It will land in 3.2, or possibly earlier - CLI releases are not tied to Cordova releases. Braden On Mon, Oct 7, 2013 at 10:57 AM, Michael Gauthier m...@silverorange.comwrote: Did this feature land in 3.1.0 or is it targeted for 3.2.0? On 2013-10-03 11:30, Michal Mocny wrote: Yeah Braden we've diverged sorry, lets focus. Big +1 for your proposal to make prepare step do what users expect. -Michal On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson bra...@chromium.org wrote: I agree that the syncing solutions are too complex and confusing. I return, then, to my original proposal all those emails ago: updating the native plugin files in platforms/foo when you prepare, to make life easier for plugin developers. When coupled with the present cordova plugin add --link, and future cordova watch, I think this makes the plugin developer flow pretty good, and without making it too magical or harder to understand. I think it simplifies prepare: on prepare, your native projects are updated to reflect the state of plugins/ and www/. Right now, only www/, assets and js-modules get updated, but not native code. As to Xcode and symlinks and all the rest of the borderline thread hijacking, I think that regardless of what editor you use, you have to be editing the right file. Xcode and Eclipse make this harder than it needs to be, but our job is not to make them suck less. Braden On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana csantan...@gmail.com wrote: +1 Anis corodova-cli/plugman should be building block components to higher level Tools/IDE. That we can do better sure, lets provide a few examples using blog pots and maybe videos tutorials vs. trying to support every use case with code. A watch function could be as simple as using grunt-contrib-watch to a more complicated environment like rsync/Eclipse I agree lets put emphasis on documenting use cases and the correct approach. When to get the best out of using prepare, merges, and hooks All I said applies when you have the Web Developer hat. For people that have the Native Plugin Developer hat then we can do things first for cordova-contributors than others can choose to use on their own risk since it could be changing too fast and maybe too narrow use case. --Carlos --Carlos On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI anis.ka...@gmail.com wrote: I gave some thought to this problem and I think we should just leave everything as is. Here's my reasoning: - Most web developers use a text editor (vim, sublime text, text mate, notepad++, ) to edit their HTML/CSS/Javascript. I've never seen anyone use a fully fledged IDE to edit web assets. It would be like using Microsoft Word to edit a simple .TXT or .MD file - Other developers, people who write Java or Objective C, etc.. use Xcode, Eclipse, IntelliJ, ...and I think these people are not good candidates for cordova-cli. The original PhoneGap promise (now Apache Cordova) was to make it easy for Web Developers to write Mobile Apps using web technologies and I believe that promise is fulfilled with cordova-cli. You have a folder where you drop in your web assets and you can build/deploy to a device or simulate. If people want to use an IDE, then they should be creating native projects with our create scripts and use plugman to manage their plugins. Our documentation should point our users to the right approach depending on the use case. For example: - Building for only one platform ? Building a hybrid app ? Want to use an IDE (Eclipse, Xcode) ? You should use the create scripts and plugman to manage plugins - Building a cross-platform app ? Like managing your project from the command-line ? Want to use your favo(u)rite text editor ? Use cordova-cli These double symlinking, backsyncing solutions will be a source of confusion and issues in my humble opinion. I've said it before but sometimes by trying to please everyone you end up pleasing no one. my .02c -a On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny mmo...@chromium.org wrote: On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve agri...@chromium.org wrote: Just tried some symlinks in Xcode 5: - Copying assets work (due to our custom build step) - Building works (compiler follows links just fine) - Editing a fail (big fail. Files open but changes cannot be saved.) Hmm, changes via xcode to symlinks fail, you mean? That would be hard to fix, but perhaps at least its feedback to the user not to make direct edits there, when using CLI workflow ;) so may still be a valid change to make. For Xcode though, it is an option to change our installation step to have Xcode reference the native files within plugins/ rather than within platforms/. Symlinks in Eclipse: - Copying assets works out-of-the-box - Build works fine - Editing
Re: Upgrading plugins using the CLI
For now, remove and add. There are plans for a more compact upgrade command in the future. In the meantime, there are some features planned that will make plugin development much friendlier, so that you won't have to run anything other than cordova prepare to get the latest plugin code. Braden On Mon, Oct 7, 2013 at 10:58 AM, Michael Gauthier m...@silverorange.comwrote: Using the CLI workflow I can add plugins with cordova plugin add name. Is there a recommended way to upgrade plugins after you've added them, or should I just plugin remove and plugin add again? Cheers, Mike
Re: PSA: watch for stipped [CB-####] from patch subject line when using git am
Ah, thanks for the clarification. I added some verbage to ContributorWorkflow to match. On Oct 2, 2013, at 9:35 PM, Andrew Grieve agri...@chromium.org wrote: That applies to cordova-js only, and I think it's a nice-to-have.
Re: Cordova versioning
Jan, if you are distributing a copy of Cordova in NetBeans, it would be nice for you to add yourself to the list of Downstream distributions at https://wiki.apache.org/cordova/FrontPage. Same for any distributors. On Oct 3, 2013, at 11:18 AM, Jan Becicka jan.beci...@oracle.com wrote: Hi, I'm a NetBeans developer and we are really close to releasing NetBeans 7.4 with support for cordova.
Re: CLI tool - Medic testing
repo README.md, cordova-docs, wiki/WorkingWithThree, … these should be cross-linked, and scoped to avoid duplication. On Oct 3, 2013, at 11:08 AM, Carlos Santana csantan...@gmail.com wrote: Even better, I prefer things like this to be closer to the source/repo
Re: Post 3.1 release committer community meeting
Okay, options are updated for the poll (http://doodle.com/2pmy2ptafmxsrna2) For those who filled it out, sorry, you will need to do it again. On Sun, Oct 6, 2013 at 7:27 PM, Michal Mocny mmo...@google.com wrote: Ugh Sorry that was a misreading of course. I'll set up a new doodle tomorrow morning. On 2013-10-06 1:52 AM, Tommy Williams to...@devgeeks.org wrote: +1 for post 16th for Joe availability. Also, thanks for thinking of Australia... One benefit of the time of year, the nasty time difference just got an hour better today... - tommy On 5 Oct 2013 08:33, Jesse purplecabb...@gmail.com wrote: I filled it out, however, Joe is not available until after the 15th. Maybe we should aim for the 16-18th as a window. @purplecabbage risingj.com On Fri, Oct 4, 2013 at 3:09 PM, Michal Mocny mmo...@chromium.org wrote: http://www.doodle.com/2pmy2ptafmxsrna2 I put a lot of options for time (sorry) since I wasn't sure if we should be europe or australia friendly this time. There are also three options this time: yes, (yes), no, where the middle option is supposed to be a prefer not, but if need be, fine -Michal On Fri, Oct 4, 2013 at 6:06 PM, Michal Mocny mmo...@chromium.org wrote: 11-15 sounds like the range to shoot for. I'll set up a doodle.. On Fri, Oct 4, 2013 at 4:48 PM, Joe Bowser bows...@gmail.com wrote: I'm unavailable until after the 15th. I'll be at Big Android BBQ.
pull request for win8
Jesse, while Carlos is out on vacation, could I ask you to put the following pull request on your to-do list? https://github.com/apache/cordova-js/pull/50 Thanks!
RE: Cordova CLI pre_package hook
Updated the changes. My CLA is already in the Apache Foundation records since last week. Thanks for the feedback. Date: Mon, 7 Oct 2013 11:03:47 -0400 Subject: Re: Cordova CLI pre_package hook From: bra...@chromium.org To: dev@cordova.apache.org I've added some comments. Ping this thread when you have a CLA on file and have made those changes, and I'll pull this change. Braden On Mon, Oct 7, 2013 at 10:17 AM, Dick Van den Brink d_vandenbr...@outlook.com wrote: Hi guys, I noticed that only the WP7 parser fired a hook (with the name pre_package) on the cordova-cli master branch when updating a project, this hook is missing in the WP8 parser so I added this hook. I also noticed that the hook on the WP7 parser didn't work correctly because the hook is fired asynchronous. I patched this in the WP7 project. I already signed the CLA so I was hoping someone could take a look at my pull request! Any feedback is appreciated. https://github.com/apache/cordova-cli/pull/43 This is my first patch for Cordova so I'm not really sure what the workflow is, should I create a issue on Jira first? I hope to write some more patches, mainly for Windows Phone, Android and maybe Windows 8. Thanks for reading :) Best regards, Dick van den Brink
Re: Mapping plugin ID - URL
https://issues.apache.org/jira/browse/CB-5006 On Thu, Oct 3, 2013 at 4:57 PM, Anis KADRI anis.ka...@gmail.com wrote: @Michal SGTM. The original approach has some other benefits on top of the current requirements. However, I don't know if we need those benefits just yet. On Thu, Oct 3, 2013 at 6:06 PM, Carlos Santana csantan...@gmail.com wrote: I think plugman is trying to do more than it should. We should look into something like bower to handle dependencies and fetching them to a local folder for a project. Bower can be use by user via cli and plugman can use it as a node library. Bower handles the download of packages/repo with it's versions/tags to a local folder. I see a cordova plugin be analogous and not that different from a package. Then plugman uses a local folder (bower_components, cordova_components, or what ever name) to install plugins from that folder. Cache only solved the problem of network usage, it doesn't solve portability of a project/repo. I'm out on vacation but wanted to bring up Bower for front-end dependencies. We can leverage their lessons learned or their code and we don't have to re-invent the wheel. TLDR: I vote for plugman to have an option for install command to skip the registry and use local folder already populated with a set of plugins. -- Carlos On Thursday, October 3, 2013, Michal Mocny wrote: On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny mmo...@chromium.org javascript:; wrote: On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI anis.ka...@gmail.com javascript:; wrote: Braden and I have talked about it in the past but there is already a $HOME/.plugman/cache and plugman will not attempt to fetch plugins if they are already in the cache. Unless I am missing something can you just not drop your dependencies in there? This sounds like it would work, but I'm hesitant to force a global installation of the cache. I think it would mean you cannot develop BB webworks apps on the same machine as you develop vanilla cordova apps since the same plugin id would map to different places across *all* plugman using projects. Note that it already has been a source of problems to have things needlessly added to ~/.cordova and ~/.plugman. Thinking about this more, I think using the global cache is subtly different than what we want here. However, I think we could perhaps leverage the concept and share most of the code. Here is the big difference: - The global plugman cache is used *after* going out to registry to lookup latest version, so as not to download the same plugin version multiple times. - This proposed local search path is to be used *before* going out to registry, without caring about its content or version number. Perhaps the current behaviour can be decomposed into two steps: (1) update global cache with newest plugin version via registry and (2) install plugin from cache. Then, installing a plugin by ID could be: - Attempt Step (2) from local search path(s) - then, if above failed, do Step (1) - then, if above succeeded, Attempt Step (2) from global cache How does that sound? Are there other use cases than simply 'not fetching from registry and using local path' for a given plugin ID ? I think this is the only use case we are looking to solve, but it shows up in different situations: during cordova plugin add ID or plugman --install with dependancy etc. #1 and #2 can be solutions to some problems but do we have those problems yet ? They can be a solution to managing multiple registry sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...) because right now we only support. Yes, we already do have these problems, as said: IBM, BB, and to some extent Mobile-Chrome-Apps is already needing this solution. Implementing a new registry would be fine, if it worked offline for local-only installs, preferably without the need to set up a server/couchdb for such simple local only mappings, which is exactly Andrews proposal. Your proposed changes also seem to only affect CLI since you mentioned a .cordova/config.json. plugman only users would potentially be penalized once again. I completely agree this is implemented in plugman. We are discussing CLI just to establish the convention for how to store the cache, but plugman would have all the underlying functionality. It *has* to be this way, since its the one that resolves dependencies, and will need a new argument alongside --install to know where to lookup id for local mapping. On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny mmo...@chromium.org wrote: I think the missing piece is that the plugin author has the option of specifying dependencies in terms exactly *one* of these options: (a) id, to
Re: Tag 2.9.1
I think we need to just have everyone go through their work over the past month and see if they missed backports. I didn't actually have very much missed, and I just backported the File plugin in the 2.9.1 branch. Of course, with backporting, we need more people to look at what was in 3.1.0 and the plugins and check to make sure we backport everything, since this is really tricky and spans all the plugin repos. :( On Mon, Oct 7, 2013 at 10:00 AM, Marcel Kinard cmarc...@gmail.com wrote: This thread seems to have gone quiet without a consensus. Should there be additional 2.9.x releases going forward? If so, how often? What kind of fixes should be backported? Include updated docs? On Oct 1, 2013, at 2:50 PM, Jesse purplecabb...@gmail.com wrote: As soon as we are done with 3.1.0 it would be a good time to go back and back-fill for a 2,9,1 release. Who's with me?
Re: Cordova for Ubuntu
Hi, Brian Whats the difference between committer and contributor? I mean what make me one or the other. Who decides? Thanks Archana On 10/7/13 6:18 AM, Brian LeRoux b...@brian.io wrote: First step is to get a CLA signed w/ Apache. [1] The next steps are to read up on how to become a committer [2] and the workflow for contribution [3] and committers [4]. I just filed an issue w/ Infra to get a new repo setup for cordova-ubuntu. [5] Not much we can do there until we have a Repo. (Sometimes bugging the Infra guys on IRC can help speed things up.) In the meantime, you can create pull requests to Plugman, CLI and Plugin* repos to our Apache mirrors for review which should be more than enough to land full commit rights. Welcome to Cordova. =) =) [1] http://www.apache.org/licenses/ [2] http://wiki.apache.org/cordova/BecomingACommitter [3] http://wiki.apache.org/cordova/ContributorWorkflow [4] http://wiki.apache.org/cordova/CommitterWorkflow [5] https://issues.apache.org/jira/browse/INFRA-6844 On Mon, Oct 7, 2013 at 12:50 AM, Maxim Ermilov maxim.ermi...@canonical.comwrote: Hello, I am working on Cordova port for Ubuntu Touch/Ubuntu. Currently it supports: 1. cli project managment 2. most of core plugins The code can be found here: https://launchpad.net/cordova-ubuntu/ https://github.com/Zaspire/cordova-plugman https://github.com/Zaspire/cordova-cli https://github.com/Zaspire/cordova-plugin-* What is the next steps for getting this into the apache repo's and merged in? _ Best regards, Maxim Ermilov
Re: Cordova for Ubuntu
Committer can commit. A contributor can send a pull request. The difference is mostly ceremonial. We ask you have some activity on the mailing list, issue tracker, and code to become a committer. On Mon, Oct 7, 2013 at 10:40 AM, Naik, Archana na...@lab126.com wrote: Hi, Brian Whats the difference between committer and contributor? I mean what make me one or the other. Who decides? Thanks Archana On 10/7/13 6:18 AM, Brian LeRoux b...@brian.io wrote: First step is to get a CLA signed w/ Apache. [1] The next steps are to read up on how to become a committer [2] and the workflow for contribution [3] and committers [4]. I just filed an issue w/ Infra to get a new repo setup for cordova-ubuntu. [5] Not much we can do there until we have a Repo. (Sometimes bugging the Infra guys on IRC can help speed things up.) In the meantime, you can create pull requests to Plugman, CLI and Plugin* repos to our Apache mirrors for review which should be more than enough to land full commit rights. Welcome to Cordova. =) =) [1] http://www.apache.org/licenses/ [2] http://wiki.apache.org/cordova/BecomingACommitter [3] http://wiki.apache.org/cordova/ContributorWorkflow [4] http://wiki.apache.org/cordova/CommitterWorkflow [5] https://issues.apache.org/jira/browse/INFRA-6844 On Mon, Oct 7, 2013 at 12:50 AM, Maxim Ermilov maxim.ermi...@canonical.comwrote: Hello, I am working on Cordova port for Ubuntu Touch/Ubuntu. Currently it supports: 1. cli project managment 2. most of core plugins The code can be found here: https://launchpad.net/cordova-ubuntu/ https://github.com/Zaspire/cordova-plugman https://github.com/Zaspire/cordova-cli https://github.com/Zaspire/cordova-plugin-* What is the next steps for getting this into the apache repo's and merged in? _ Best regards, Maxim Ermilov
Re: Cordova for Ubuntu
Thanks Brian. So for a contributor, after sending pull requests what are the next steps? Does contributor also send review-board requests? If approved who merges code to apache git from contributor's fork or repo? Archana On 10/7/13 10:52 AM, Brian LeRoux b...@brian.io wrote: Committer can commit. A contributor can send a pull request. The difference is mostly ceremonial. We ask you have some activity on the mailing list, issue tracker, and code to become a committer. On Mon, Oct 7, 2013 at 10:40 AM, Naik, Archana na...@lab126.com wrote: Hi, Brian Whats the difference between committer and contributor? I mean what make me one or the other. Who decides? Thanks Archana On 10/7/13 6:18 AM, Brian LeRoux b...@brian.io wrote: First step is to get a CLA signed w/ Apache. [1] The next steps are to read up on how to become a committer [2] and the workflow for contribution [3] and committers [4]. I just filed an issue w/ Infra to get a new repo setup for cordova-ubuntu. [5] Not much we can do there until we have a Repo. (Sometimes bugging the Infra guys on IRC can help speed things up.) In the meantime, you can create pull requests to Plugman, CLI and Plugin* repos to our Apache mirrors for review which should be more than enough to land full commit rights. Welcome to Cordova. =) =) [1] http://www.apache.org/licenses/ [2] http://wiki.apache.org/cordova/BecomingACommitter [3] http://wiki.apache.org/cordova/ContributorWorkflow [4] http://wiki.apache.org/cordova/CommitterWorkflow [5] https://issues.apache.org/jira/browse/INFRA-6844 On Mon, Oct 7, 2013 at 12:50 AM, Maxim Ermilov maxim.ermi...@canonical.comwrote: Hello, I am working on Cordova port for Ubuntu Touch/Ubuntu. Currently it supports: 1. cli project managment 2. most of core plugins The code can be found here: https://launchpad.net/cordova-ubuntu/ https://github.com/Zaspire/cordova-plugman https://github.com/Zaspire/cordova-cli https://github.com/Zaspire/cordova-plugin-* What is the next steps for getting this into the apache repo's and merged in? _ Best regards, Maxim Ermilov
Re: Cordova for Ubuntu
Good question. I just added a couple paragraphs to the top of http://wiki.apache.org/cordova/BecomingACommitter Please feel free to edit my explanation and improve it. On Oct 7, 2013, at 1:52 PM, Brian LeRoux b...@brian.io wrote: Committer can commit. A contributor can send a pull request. The difference is mostly ceremonial. We ask you have some activity on the mailing list, issue tracker, and code to become a committer. On Mon, Oct 7, 2013 at 10:40 AM, Naik, Archana na...@lab126.com wrote: Hi, Brian Whats the difference between committer and contributor? I mean what make me one or the other. Who decides? Thanks Archana
Re: Cordova for Ubuntu
Yes, review board is preferred between committers (I think, sometimes) but not obv not the only way. I prefer pull requests and imagine that is more familiar to someone new. It will be reviewed and merged by a platform maintainer (usually) or another committer. On Mon, Oct 7, 2013 at 11:09 AM, Naik, Archana na...@lab126.com wrote: Thanks Brian. So for a contributor, after sending pull requests what are the next steps? Does contributor also send review-board requests? If approved who merges code to apache git from contributor's fork or repo? Archana On 10/7/13 10:52 AM, Brian LeRoux b...@brian.io wrote: Committer can commit. A contributor can send a pull request. The difference is mostly ceremonial. We ask you have some activity on the mailing list, issue tracker, and code to become a committer. On Mon, Oct 7, 2013 at 10:40 AM, Naik, Archana na...@lab126.com wrote: Hi, Brian Whats the difference between committer and contributor? I mean what make me one or the other. Who decides? Thanks Archana On 10/7/13 6:18 AM, Brian LeRoux b...@brian.io wrote: First step is to get a CLA signed w/ Apache. [1] The next steps are to read up on how to become a committer [2] and the workflow for contribution [3] and committers [4]. I just filed an issue w/ Infra to get a new repo setup for cordova-ubuntu. [5] Not much we can do there until we have a Repo. (Sometimes bugging the Infra guys on IRC can help speed things up.) In the meantime, you can create pull requests to Plugman, CLI and Plugin* repos to our Apache mirrors for review which should be more than enough to land full commit rights. Welcome to Cordova. =) =) [1] http://www.apache.org/licenses/ [2] http://wiki.apache.org/cordova/BecomingACommitter [3] http://wiki.apache.org/cordova/ContributorWorkflow [4] http://wiki.apache.org/cordova/CommitterWorkflow [5] https://issues.apache.org/jira/browse/INFRA-6844 On Mon, Oct 7, 2013 at 12:50 AM, Maxim Ermilov maxim.ermi...@canonical.comwrote: Hello, I am working on Cordova port for Ubuntu Touch/Ubuntu. Currently it supports: 1. cli project managment 2. most of core plugins The code can be found here: https://launchpad.net/cordova-ubuntu/ https://github.com/Zaspire/cordova-plugman https://github.com/Zaspire/cordova-cli https://github.com/Zaspire/cordova-plugin-* What is the next steps for getting this into the apache repo's and merged in? _ Best regards, Maxim Ermilov
Plugins Release
Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Cordova for Ubuntu
Thanks Marcel. I just got the email about your wiki changes. I will read it soon. :) On 10/7/13 11:22 AM, Marcel Kinard cmarc...@gmail.com wrote: Good question. I just added a couple paragraphs to the top of http://wiki.apache.org/cordova/BecomingACommitter Please feel free to edit my explanation and improve it. On Oct 7, 2013, at 1:52 PM, Brian LeRoux b...@brian.io wrote: Committer can commit. A contributor can send a pull request. The difference is mostly ceremonial. We ask you have some activity on the mailing list, issue tracker, and code to become a committer. On Mon, Oct 7, 2013 at 10:40 AM, Naik, Archana na...@lab126.com wrote: Hi, Brian Whats the difference between committer and contributor? I mean what make me one or the other. Who decides? Thanks Archana
Re: Plugins Release
I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.orgwrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.comwrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.orgwrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
If we want to do CLI/Plugman, we definitely will need to do more testing and fix some things (like FFOS). I think we also need to make sure that some of the changes that went into cordova-3.1.x branches also ended up in the refactored master branches. I will plan on doing the plugins release tomorrow/Wednesday. Steve On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve agri...@chromium.org wrote: I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
https://issues.apache.org/jira/browse/CB-5010 On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill stevengil...@gmail.com wrote: If we want to do CLI/Plugman, we definitely will need to do more testing and fix some things (like FFOS). I think we also need to make sure that some of the changes that went into cordova-3.1.x branches also ended up in the refactored master branches. I will plan on doing the plugins release tomorrow/Wednesday. Steve On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve agri...@chromium.orgwrote: I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: pull request for win8
It already is. Sent from my iPad On Oct 7, 2013, at 10:09 AM, Marcel Kinard cmarc...@gmail.com wrote: Jesse, while Carlos is out on vacation, could I ask you to put the following pull request on your to-do list? https://github.com/apache/cordova-js/pull/50 Thanks!
Re: Tag 2.9.1
Yes, now that 3.1.0 is out the door, we can do this. Sent from my iPad On Oct 7, 2013, at 10:36 AM, Joe Bowser bows...@gmail.com wrote: I think we need to just have everyone go through their work over the past month and see if they missed backports. I didn't actually have very much missed, and I just backported the File plugin in the 2.9.1 branch. Of course, with backporting, we need more people to look at what was in 3.1.0 and the plugins and check to make sure we backport everything, since this is really tricky and spans all the plugin repos. :( On Mon, Oct 7, 2013 at 10:00 AM, Marcel Kinard cmarc...@gmail.com wrote: This thread seems to have gone quiet without a consensus. Should there be additional 2.9.x releases going forward? If so, how often? What kind of fixes should be backported? Include updated docs? On Oct 1, 2013, at 2:50 PM, Jesse purplecabb...@gmail.com wrote: As soon as we are done with 3.1.0 it would be a good time to go back and back-fill for a 2,9,1 release. Who's with me?
