Re: Introduction

[Lorin Beer]

welcome Tim!

On Thu, Nov 20, 2014 at 11:16 AM, Shazron  wrote:

> Welcome aboard Tim!
>
> On Thu, Nov 20, 2014 at 11:13 AM, Tim Barham 
> wrote:
>
> > Hi all,
> >
> > My name is Tim Barham, and I'm on the Visual Studio team at Microsoft. I
> > have been a part of the team that has been working on Cordova support for
> > Visual Studio, and now I would like to contribute directly to Cordova, so
> > hopefully you'll be seeing more of me around here!
> >
> > The first change I hope to make is to fix bug
> > https://issues.apache.org/jira/browse/CB-8053 - fixing the Windows
> > "addProjectReference" logic to handle multiple projects in a solution
> file,
> > and multiple solution files (which is a possibility now with support for
> > universal apps). I've submitted my signed ICLA, and have a fix for the
> bug
> > ready to go, so hope to submit my first pull request shortly.
> >
> > Thanks!
> >
> > Tim
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: Stale branches in cordova-js (and others)

[Lorin Beer]

+1, merged feature branches should be deleted

pinging the relevant committers so they can come rescue anything they want
to save would be prudent for the 4. stale/abandoned branches.

On Wed, Oct 22, 2014 at 10:14 AM, Joe Bowser  wrote:

> Agreed. We should delete feature branches once they're merged in.  That
> said, we should have a LOT more feature branches.
>
> On Wed, Oct 22, 2014 at 9:52 AM, Josh Soref  wrote:
>
> > There are a number of branches in cordova-js.
> > I think there should be two kinds of branches:
> >
> > 1. Release branches (or tags that are created as branches)
> > 2. Feature branches
> >
> > Well, two other kinds of branches:
> > 3. Merged feature branches
> > 4. Stale/abandoned branches
> >
> > I'd like to remove things that fall into #3/#4:
> >
> > Merged:
> > * future (bhiggins)
> > * pl (filmaj)
> >
> > Stale/abandoned:
> > * playbookFile (timkim) -- note that cordova no longer supports
> PlayBook...
> > * bb_media_fix (timkim)
> > * async_base64_android (agrieve) -- there's no sign of this being merged
> > in, and no obvious sign of a bug for it
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: adding push notifications to core plugins

[Lorin Beer]

I've been asked about this from multiple sources over the last few weeks.
Given how important push notifications are for mobile projects, a core push
notification plugin would be a great addition and another argument for why
you should use cordova.

On Thu, Oct 16, 2014 at 11:58 AM, Brian LeRoux  wrote:

> just was discussing w/ Shaz and Jesse…thoughts?
>

Re: continuous integration woze

[Lorin Beer]

+1 to fixing the test
-1 to warnings

warnings are either treated like errors, or ignored entirely. I'm for
treating warnings like errors in the first place


On Thu, Aug 21, 2014 at 1:53 PM, Marcel Kinard  wrote:

> I agree. My personal philosophy is generally to treat warnings as errors.
>
> On Aug 21, 2014, at 9:27 AM, Mark Koudritsky  wrote:
>
> > If some tests are too strict or too flaky, we can and should fix or
> remove
> > them altogether. I don't believe there is any value in warnings, they
> will
> > accumulate and then people will largely ignore them.
>
>

Re: Andrew on Vacation

[Lorin Beer]

enjoy!


On Fri, Aug 22, 2014 at 1:54 AM, Ally Ogilvie  wrote:

> Enjoy!
>
>
> On Fri, Aug 22, 2014 at 3:57 PM, Steven Gill 
> wrote:
>
> > Have a good one!
> >
> > On Thursday, August 21, 2014, Andrew Grieve  wrote:
> >
> > > I'll be back Sept 8th :)
> > >
> >
>
>
>
> --
> Ally Ogilvie
> Lead Developer - MobDev. | Wizcorp Inc. 
> --
> TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 | Website
>  | Twitter  |
> Facebook
>  | LinkedIn
> 
>

Re: CB-7312 Camera Plugin uri scheme

[Lorin Beer]

+1 for documenting how uri's should be treated as per Josh's suggestion

-1 for documenting in Next Steps or File Plugin, it would make this
information extremely hard to find. How about a "URI's, Cordova and You"
document for the core Cordova docs?


On Tue, Aug 19, 2014 at 12:13 PM, Marcel Kinard  wrote:

> +1. Candidate for best practices section in "Next Steps" guide, or in the
> File plugin docs?
>
> On Aug 19, 2014, at 9:49 AM, Josh Soref  wrote:
>
> > Vivek wrote:
> >> Should'nt the camera plugin be standardized to return a common uri
> >> scheme, By converting to a standard uri scheme before passing it to the
> >> callbackContext.
> >
> > URIs should be treated as opaque. You shouldn't be relying on the URI to
> > be anything, beyond something which can be resolved/loaded.
> >
> > I'm not opposed to picking some random protocol, but I'd rather we
> > actively document that people should not be trying to parse URIs for any
> > particular purpose, and should treat them as opaque references to data.
> >
>
>

Re: Hello Cordova!

[Lorin Beer]

Welcome Nikolai!


On Sun, Aug 17, 2014 at 5:02 PM, tommy-carlos williams 
wrote:

> Welcome!
>
> On 18 August 2014 at 8:59:55, Nikolai Kotchetkov (moto...@gmail.com)
> wrote:
>
> Hello Cordova!
>
> My name is Nikolai, and I've been taking part in several Cordova projects
> already mostly by writing plugins for Android.
>
> At this time I'd like to contribute a small feature to make a plugin
> handling a bit easier :)
> https://github.com/apache/cordova-lib/pull/63
>
> My ICLA is on it's way to secretary :)
>
> Best regards,
> Nikolai
>
>

Re: Remove VERSION file from repos

[Lorin Beer]

the version scripts are just about the only thing about the platform
scripts that are simple enough to rewrite trivially. Leveraging a
rewrite/refactor of the version script into a total rewrite of platform
level scripts == 'lulz'



On Tue, Aug 12, 2014 at 1:15 PM, Jesse  wrote:

> the non-cordova cli path depends on node to install/uninstall plugins
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Aug 12, 2014 at 1:08 PM, Shazron  wrote:
>
> > Of course I considered nodejs, but no, this is for the non-cordova CLI
> > path, which does not need another dependency.
> >
> > On Tue, Aug 12, 2014 at 11:52 AM, Jesse  wrote:
> > > Yeah, if you are going to replace bash, replace it with nodejs!
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Tue, Aug 12, 2014 at 11:48 AM, Myles Borins  wrote:
> > >
> > >> Have you considered writing a small node script to pass the json? This
> > >> would make it as simple as requiring in the package json an piping the
> > >> relevant info to stdout
> > >> On Aug 12, 2014 11:47 AM, "Shazron"  wrote:
> > >>
> > >> > Yeah I value life and my sanity - I'll probably replace the bash
> > >> > script with python
> > >> >
> > >> > On Tue, Aug 12, 2014 at 11:40 AM, Lorin Beer 
> > >> wrote:
> > >> > > one source for version information is better
> > >> > >
> > >> > > although parsing json with bash scripts seems janky
> > >> > >
> > >> > >
> > >> > > On Tue, Aug 12, 2014 at 11:31 AM, Jesse 
> > >> wrote:
> > >> > >
> > >> > >> I think it still needs to exist in an output project ... which is
> > not
> > >> > >> (yet?) an npm project, and so does not have a package.json.
> > >> > >>
> > >> > >> The individual platform repos can get rid of it, they will just
> > need
> > >> to
> > >> > >> modify the way they `create` new projects to read the value from
> > >> > >> package.json and output it to NewProject/VERSION
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> @purplecabbage
> > >> > >> risingj.com
> > >> > >>
> > >> > >>
> > >> > >> On Tue, Aug 12, 2014 at 11:25 AM, Shazron 
> > wrote:
> > >> > >>
> > >> > >> > For iOS, the only file I can see that depends on this is:
> > >> > >> >
> > >> > >> > 1.
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> >
> https://github.com/apache/cordova-ios/blob/master/bin/templates/scripts/cordova/version
> > >> > >> >
> > >> > >> > Not sure of the alternative.
> > >> > >> >
> > >> > >> > This references it but can be removed:
> > >> > >> > https://github.com/apache/cordova-ios/blob/master/bin/create
> > >> > >> >
> > >> > >> >
> > >> > >> > On Tue, Aug 12, 2014 at 11:19 AM, Steven Gill <
> > >> stevengil...@gmail.com
> > >> > >
> > >> > >> > wrote:
> > >> > >> > > Most of our repos have a package.json. It keeps track of
> > >> versions. I
> > >> > >> > think
> > >> > >> > > we should work towards removing the VERSION files from the
> > repos
> > >> we
> > >> > >> can.
> > >> > >> > >
> > >> > >> > > Thoughts?
> > >> > >> > >
> > >> > >> > > This would require some changes to coho so it doesn't try to
> > >> update
> > >> > the
> > >> > >> > > version file when doing releases.
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> >
>

Re: Remove VERSION file from repos

[Lorin Beer]

one source for version information is better

although parsing json with bash scripts seems janky


On Tue, Aug 12, 2014 at 11:31 AM, Jesse  wrote:

> I think it still needs to exist in an output project ... which is not
> (yet?) an npm project, and so does not have a package.json.
>
> The individual platform repos can get rid of it, they will just need to
> modify the way they `create` new projects to read the value from
> package.json and output it to NewProject/VERSION
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Aug 12, 2014 at 11:25 AM, Shazron  wrote:
>
> > For iOS, the only file I can see that depends on this is:
> >
> > 1.
> >
> https://github.com/apache/cordova-ios/blob/master/bin/templates/scripts/cordova/version
> >
> > Not sure of the alternative.
> >
> > This references it but can be removed:
> > https://github.com/apache/cordova-ios/blob/master/bin/create
> >
> >
> > On Tue, Aug 12, 2014 at 11:19 AM, Steven Gill 
> > wrote:
> > > Most of our repos have a package.json. It keeps track of versions. I
> > think
> > > we should work towards removing the VERSION files from the repos we
> can.
> > >
> > > Thoughts?
> > >
> > > This would require some changes to coho so it doesn't try to update the
> > > version file when doing releases.
> >
>

Re: your blog feed has errors

[Lorin Beer]

Thanks for pointing this out Paul,

looks to involve minor fixes, most of the generated errors are date/time
formatting related


On Tue, Aug 12, 2014 at 8:30 AM, Andrew Grieve  wrote:

> Thanks for pointing this out Paul. I've created an issue for it:
> https://issues.apache.org/jira/browse/CB-7292
>
>
> On Sat, Aug 9, 2014 at 12:47 PM, Paul Topping  wrote:
>
> > Just FYI. Here's output from
> >
> http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fcordova.apache.org%2Frss.xml
> >
> >
> >
> > This feed does not validate.
> >
> >
> >
> > line 42, column 41: pubDate must be an RFC-822 date-time: Wed, 06 Aug
> > 2014 (21 occurrences) [help]
> >
> >
> >
> > Wed, 06 Aug 2014
> >
> >  ^
> >
> >
> >
> > line 3287, column 37: XML parsing error: :3287:37: not
> > well-formed (invalid token) [help]
> >
> >
> >
> > CLI, Plugman & Plugins Release: Oct 28,
> > 2013
> >
> >  ^
> >
> >
> >
> > In addition, interoperability with the widest range of feed readers could
> > be improved by implementing the following recommendation.
> >
> >
> >
> > line 12, column 42: Image not in required format [help]
> >
> >
> >
> > http://cordova.apache.org
> >
>

Re: Chrome-axiom

[Lorin Beer]

OP Delivers!


On Tue, Aug 12, 2014 at 8:58 AM, Andrew Grieve  wrote:

> But since I've piqued your interests now, that's an internal codename for
> Chrome Dev Editor: https://github.com/dart-lang/chromedeveditor
>
>
>
>
> On Tue, Aug 12, 2014 at 11:54 AM, Ray Camden  wrote:
>
> > Do you have an external URL? :)
> > 
> > From: Andrew Grieve 
> > Sent: Tuesday, August 12, 2014 10:49 AM
> > To: dev
> > Subject: Chrome-axiom
> >
> > New mailinglist that it may be worth joining.
> >
> > "Chrome Axiom is the Chrome Developer Tooling platform. We're building
> the
> > well lit path for web developers to succeed."
> >
> > http://goto/chrome-axiom
> >
>

Re: Hello

[Lorin Beer]

Welcome Jason!


On Thu, Aug 7, 2014 at 9:55 AM, Sebastian Mil 
wrote:

> Hi Jason!
>
>
> On Thu, Aug 7, 2014 at 9:50 AM, Carlos Santana 
> wrote:
>
> > Welcome Jason !
> >
> >
> > On Thu, Aug 7, 2014 at 10:19 AM, Jason Chase 
> wrote:
> >
> > > Hi all,
> > >
> > > I'm Jason Chase, and I just joined the Google team working on Cordova.
> > >
> > > I've spent the last while working on enterprise SaaS solution, so I'm
> > > looking forward to the challenge of getting up to speed on Cordova.
> >  Looks
> > > like there's a lot going on with Cordova, so I can't wait to
> contribute!
> > >
> > > Thanks,
> > > Jason
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > 
> >
>

Re: NodeJS Hooks dependencies?

[Lorin Beer]

thanks Myles, nice to see you on the list!


On Tue, Aug 5, 2014 at 2:33 PM, Myles Borins  wrote:

> If you have a package.json at the base of the project any dependencies
> installed in the node_modules folder will be resolved at any depth.  You
> should only need to do a single install at the base of hook.  Do you have a
> copy of the project I could take a peek at?
>
> If the cordovaUserProject itself already has a package.json you should
> just add the dependencies in there and they will automatically be added to
> the path when required in by the scripts (and only need to be installed at
> the same time the user does the initial bootstrap).  If you were interested
> in abstracting these scripts further it is possible to build node modules
> that expose binaries through the ‘bin’ key in the package json.  You would
> then be able to reference these scripts directly in an npm script without
> specific paths, as they will be installed into ./node_modules/.bin, which
> is shimmed into path of an npm script.
>
> This would allow you to add the following to the single package.json
>
> scripts: {
> bootstrap: ‘prepare’,
> compile: ‘some bash script that compiles’,
> post: ‘compile’,
> build: ‘npm run bootstrap && npm run compile && npm run post’
> }
>
> then in your project (or any script) you could simply run ‘npm build’ and
> it would all work!
>
> Please let me know if any of that wasn’t clear.  It is worth mentioning
> that install scripts are generally considered an anti-pattern in the node
> community (as it states in the docs
> https://www.npmjs.org/doc/misc/npm-scripts.html).  Clever concatenation
> of bash scripts is considered elegant though!
>
> Best,
>
> Myles Borins
>
> On Aug 5, 2014, at 2:22 PM, Lorin Beer  wrote:
>
> > a suggestion:
> >
> > as part of the hook script, have it attempt an npm install iff the
> > dependencies are not present. You can hide the require calls in a
> > try/catch, if caught, then run an install script in the relevant hook
> > directories.
> >
> > If admin privileges are required for the install, prompt for credentials,
> > or tell the user to change the directory permissions...
> >
> > Don't know about 'best practice', but it's light weight and doesn't force
> > the user to execute an intermediate install step.
> >
> >
> >
> > On Tue, Aug 5, 2014 at 1:00 PM, Carlos Santana 
> wrote:
> >
> >> I'm writing new cordova hooks, and decided to do them in nodejs
> >>
> >> First problem I hit was dependencies for the hook scripts:
> >> so far I have two scripts:
> >> cordovaUserProject/hook/before_prepare/wl_b_prepare.js
> >> cordovaUserProject/hook/after_compile/wl_a_compile.js
> >>
> >> I have both starting like this:
> >> #!/usr/bin/env node
> >>
> >> var shell = require('shelljs'),
> >> nopt  = require('nopt');
> >>
> >> shell.echo('Running Worklight Cordova Hook');
> >>
> >>
> >> I get errors because it can't find dependencies 'shelljs' and 'nopt'
> >>
> >> To resolve this I would need the user or another hook before this one to
> >> install the node_modules in one of these places
> >>
> >> cordovaUserProject/node_modules/
> >> cordovaUserProject/hook/node_modules/
> >> cordovaUserProject/hook/before_prepare/node_modules/
> >> cordovaUserProject/hook/after_compile/node_modules/
> >>
> >> What would be a best practice?
> >> Who get's to install? (user or me)
> >> Where to install?
> >>
> >>
> >>
> >> --
> >> Carlos Santana
> >> 
> >>
>
>

Re: NodeJS Hooks dependencies?

[Lorin Beer]

a suggestion:

as part of the hook script, have it attempt an npm install iff the
dependencies are not present. You can hide the require calls in a
try/catch, if caught, then run an install script in the relevant hook
directories.

If admin privileges are required for the install, prompt for credentials,
or tell the user to change the directory permissions...

Don't know about 'best practice', but it's light weight and doesn't force
the user to execute an intermediate install step.



On Tue, Aug 5, 2014 at 1:00 PM, Carlos Santana  wrote:

> I'm writing new cordova hooks, and decided to do them in nodejs
>
> First problem I hit was dependencies for the hook scripts:
> so far I have two scripts:
> cordovaUserProject/hook/before_prepare/wl_b_prepare.js
> cordovaUserProject/hook/after_compile/wl_a_compile.js
>
> I have both starting like this:
> #!/usr/bin/env node
>
> var shell = require('shelljs'),
> nopt  = require('nopt');
>
> shell.echo('Running Worklight Cordova Hook');
>
>
> I get errors because it can't find dependencies 'shelljs' and 'nopt'
>
> To resolve this I would need the user or another hook before this one to
> install the node_modules in one of these places
>
> cordovaUserProject/node_modules/
> cordovaUserProject/hook/node_modules/
> cordovaUserProject/hook/before_prepare/node_modules/
> cordovaUserProject/hook/after_compile/node_modules/
>
> What would be a best practice?
> Who get's to install? (user or me)
> Where to install?
>
>
>
> --
> Carlos Santana
> 
>

Re: Contributawesome

[Lorin Beer]

Hi Adam,

welcome to the list!


On Wed, Jul 30, 2014 at 4:01 PM, Adam Cmiel  wrote:

> Dear Apache Cordova,
>
> I’m Adam and I’ve been working with Cordova for the past two years, and am
> excited to join the contributorship.  I have already signed the CLA and
> submitted it to the Apache secretary, subscribed to the dev list, and
> created a Jira account.  I’m particularly interested in improving the
> quality of Cordova documentation and improving the user experience with the
> CLI tools and generating their apps.
>
> Best,
> Adam
>
> Github:
> @adamcmiel
>

Re: Contributing to Cordova

[Lorin Beer]

Hi Sebastian, welcome!


On Wed, Jul 30, 2014 at 1:47 PM, Sebastian Mil 
wrote:

> Dear Apache Cordova,
>
> I am a student studying EECS at UC Berkeley and work at Famo.us. I am
> interested in mobile development and developing my coding skills.
>
> During the past few weeks I created a few apps with Cordova and Famo.us. I
> have come across a few things that I would like to improve upon within
> Cordova. I am interested in becoming a committer. I have started by signing
> the CLA, subscribing to the Cordova Dev List, reading the wiki on workflow
> and have an account on jira. I already know a few issues that I would like
> to submit fixes for in jira, I am just waiting for conformation that my CLA
> has been processed.
>
> Cheers,
> --Sebastian Miller-Hack
>   github: sebastianmh
>

Re: out

[Lorin Beer]

Just spitballin' here:

http://www.businessinsider.com/how-to-get-out-of-jury-duty-2012-7?op=1

insist that you will educate your jury peers on 'jury nullification'.

wear camo pants

On Wed, Jul 30, 2014 at 2:36 PM, Jesse  wrote:

> 2 words, not guilty!
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Jul 30, 2014 at 2:32 PM, Marcel Kinard  wrote:
>
> > I've been called in for jury duty tomorrow. So if I'm silent here, it's
> > not because I'm blowing people off. I hope this will be for just 1 day,
> but
> > that may not be the case (insert rim shot here).
>

Re: Famo.us & cordova?

[Lorin Beer]

Brian and I have been speaking with Famo.us. So far, no technical specifics
have been discussed or finalized. They do have a demoable wrapper for
cordova, which I believe was developed as a proof of concept.

Joe: I read that as (Adobe) (Cordova Team)

I'll have more information to relay once I'm back from PTO next week and
start up the conversation with famo.us.


On Tue, Jul 8, 2014 at 6:00 AM, Michal Mocny  wrote:

> I'm not concerned about that part Joe.  I'm a little concerned about the
> way they worded the second part.  It sounds like its something custom they
> are building, that isn't related to cordova at all.  I'm assuming it is,
> but talk about questionable writeup (gasp, surprise for Famo.us).
>
>
> On Tue, Jul 8, 2014 at 12:02 AM, Joe Bowser  wrote:
>
> > WTF is Adobe Cordova? I know that someone was talking to the Famo.us
> > guys, but they really screwed up this mailout. :S
> >
> > On Mon, Jul 7, 2014 at 8:59 PM, Michal Mocny  wrote:
> > > From todays Famo.us email marketting:
> > >
> > >
> > > *Adobe collaboration*
> > > We are proud to announce that we have officially begun a collaboration
> > > project with the Adobe Cordova team to make core improvements to
> Cordova
> > > itself. Included as part of this project will be a section of Famo.us
> > > University to teach people how to wrap Famo.us apps.
> > >
> > > *The Famo.us Wrapper*
> > > The wrapper will enable developers to create a pluggable webview
> wrapped
> > > inside their Android apps. The good news is that you can provide a
> Chrome
> > > 35 webview with this method. The bad news is that it comes with a
> 10-20MB
> > > payload. We are collaborating with another company on this
> project—sorry,
> > > but we can't say their name yet. This solution is in the labs and is
> not
> > > ready for production. We will let you know when it is available. If
> you'd
> > > like to participate in our beta, please contact fetter...@famo.us.
> >
>

Re: Cordova hooks always verbose.

[Lorin Beer]

as someone who uses hooks, I think that's a good idea

1. non verbose mode should simply output something like "running X hooks"
2. verbose mode can output more details of the scripts being run

On Fri, Jun 13, 2014 at 1:05 PM, Michal Mocny  wrote:
> https://issues.apache.org/jira/browse/CB-6942
>
>
> On Fri, Jun 13, 2014 at 3:51 PM, Michal Mocny  wrote:
>
>> Hey all,
>>
>> I'd like to change cordova-cli to not always print multiple messages like
>> "Running command: ..." when it runs hooks.  I'd like this to happen only if
>> you have verbose logging on (with -d or --verbose).
>>
>> I think this was a regression added in February, but since its been in a
>> few releases with no complaints (likely because most projects don't use
>> hooks), I wonder if others feel this is a useful default (I don't think it
>> is)?
>>
>> Tommy: you guys use hooks in your projects a lot, what do you think?
>>
>> If it is a useful default, I'll instead add a way to opt-out without
>> disabling absolutely all logging with --silent.
>>
>> -Michal
>>

Re: minor bump to cordova-lib

[Lorin Beer]

good. lord.

On Mon, Jun 9, 2014 at 1:04 PM, Michal Mocny  wrote:
> We all wish!
>
>
> On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer  wrote:
>
>> Michal: the root package.json is being removed. I do want to perform
>> an npm publish with a patch version increment, so downstream projects
>> can reference include by npm registry and not git url. That would
>> constitute a 'release' of some sort. My understanding was that bug
>> patches of this sort could be pushed out with minimum fuss.
>>
>>
>> On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny  wrote:
>> > In particular, I thought the root of the repo wasn't supposed to be a
>> node
>> > package, but a bucket for multiple node packages.  (ie, should not be a
>> > package.json at the root).
>> >
>> > We don't vote on commits (though its nice to ask for review for big hairy
>> > patches like this one, so thanks for that).
>> >
>> > -Michal
>> >
>> >
>> > On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve 
>> wrote:
>> >
>> >> I think all releases require votes. Only difference is that for urgent
>> >> releases we can have a shorter vote period.
>> >>
>> >> Looking at your commit - there's now two package.json files with the
>> same
>> >> name. I don't think that's allowed by npm.
>> >>
>> >> Your goal was to make configparser its own package right? Doesn't it
>> need
>> >> its own package.json file to be its own package?
>> >>
>> >>
>> >> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer 
>> wrote:
>> >>
>> >> > Minor bump to cordova-lib to expose a broken out package.
>> >> >
>> >> > history:
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
>> >> >
>> >> > squashed commit to master:
>> >> >
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
>> >> >
>> >> >
>> >> > This does not change any functionality of the modules, just the way
>> >> > they are wired up. It also provides an additional package.json file to
>> >> > better expose the cordova-lib submodules.
>> >> >
>> >> >
>> >> > I think that qualifies as a patch, and should not require a release
>> vote.
>> >> >
>> >> > I will hold off on npm publish for some feedback
>> >> >
>> >> > - Lorin
>> >> >
>> >>
>>

Re: minor bump to cordova-lib

[Lorin Beer]

Michal: the root package.json is being removed. I do want to perform
an npm publish with a patch version increment, so downstream projects
can reference include by npm registry and not git url. That would
constitute a 'release' of some sort. My understanding was that bug
patches of this sort could be pushed out with minimum fuss.


On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny  wrote:
> In particular, I thought the root of the repo wasn't supposed to be a node
> package, but a bucket for multiple node packages.  (ie, should not be a
> package.json at the root).
>
> We don't vote on commits (though its nice to ask for review for big hairy
> patches like this one, so thanks for that).
>
> -Michal
>
>
> On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve  wrote:
>
>> I think all releases require votes. Only difference is that for urgent
>> releases we can have a shorter vote period.
>>
>> Looking at your commit - there's now two package.json files with the same
>> name. I don't think that's allowed by npm.
>>
>> Your goal was to make configparser its own package right? Doesn't it need
>> its own package.json file to be its own package?
>>
>>
>> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer  wrote:
>>
>> > Minor bump to cordova-lib to expose a broken out package.
>> >
>> > history:
>> >
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
>> >
>> > squashed commit to master:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
>> >
>> >
>> > This does not change any functionality of the modules, just the way
>> > they are wired up. It also provides an additional package.json file to
>> > better expose the cordova-lib submodules.
>> >
>> >
>> > I think that qualifies as a patch, and should not require a release vote.
>> >
>> > I will hold off on npm publish for some feedback
>> >
>> > - Lorin
>> >
>>

Re: minor bump to cordova-lib

[Lorin Beer]

looking into the duplicate package.json issue

thanks for catching the package.json issue, the duplicate is a
mistaken inclusion

the end goal is that configparser is it's own package, yes. Included
the wrong package.json file

On Mon, Jun 9, 2014 at 12:01 PM, Andrew Grieve  wrote:
> I think all releases require votes. Only difference is that for urgent
> releases we can have a shorter vote period.
>
> Looking at your commit - there's now two package.json files with the same
> name. I don't think that's allowed by npm.
>
> Your goal was to make configparser its own package right? Doesn't it need
> its own package.json file to be its own package?
>
>
> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer  wrote:
>
>> Minor bump to cordova-lib to expose a broken out package.
>>
>> history:
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module
>>
>> squashed commit to master:
>>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654
>>
>>
>> This does not change any functionality of the modules, just the way
>> they are wired up. It also provides an additional package.json file to
>> better expose the cordova-lib submodules.
>>
>>
>> I think that qualifies as a patch, and should not require a release vote.
>>
>> I will hold off on npm publish for some feedback
>>
>> - Lorin
>>

minor bump to cordova-lib

[Lorin Beer]

Minor bump to cordova-lib to expose a broken out package.

history: 
https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module

squashed commit to master:
https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654


This does not change any functionality of the modules, just the way
they are wired up. It also provides an additional package.json file to
better expose the cordova-lib submodules.


I think that qualifies as a patch, and should not require a release vote.

I will hold off on npm publish for some feedback

- Lorin

Re: wip on cordova-lib? pls let us know

[Lorin Beer]

Here's a wip for the breakout of the config parser module

https://github.com/lorinbeer/cordova-lib/tree/configparser_module

still need to tidy up the referencing but feedback welcome

On Fri, Jun 6, 2014 at 11:03 AM, Anis KADRI  wrote:
> The goal is to have independent modules that can be consumed.
>
> Andrew, your second example reflects what we want to achieve. Obviously,
> there will be more than CordovaError. Brian and I think that we can keep
> the current cordova-lib repository and create folders for each module (each
> with its own dependencies and package.json). Eventually, there could be
> more repositories if we chose to have them.
>
> Right now if you just want one piece of functionality from either plugman
> or cli you need the whole cordova-lib module which is extremely unfortunate
> and pretty silly.
>
>
> On Fri, Jun 6, 2014 at 10:55 AM, Michal Mocny  wrote:
>
>> Additionally, I think it will only be a problem when each of the modules
>> call into one another.  I.e. when cordova-cli calls into cordova-plugman
>> and that throws a CordovaError which is caught by cordova-cli and then
>> compared with instanceof to its own version..  Its not a problem in
>> isolation.
>>
>> This problem usually comes up with singletons / internal caching, such as
>> reading config files from disk once and then modifying in-memory, but I'm
>> not sure if we actyally have that problem.
>>
>> -Michal
>>
>>
>> On Fri, Jun 6, 2014 at 1:12 PM, Andrew Grieve 
>> wrote:
>>
>> > On Fri, Jun 6, 2014 at 12:37 PM, Brian LeRoux  wrote:
>> >
>> > > Ya I spoke to Issac a bit about this last week and he wasn't being
>> > entirely
>> > > facetious. One path that apparently works well is to treat root
>> > > `./node_modules` as something npm manages and then nested node_modules
>> > for
>> > > userspace stuff.
>> > >
>> > > eg. `./src/node_modules` and then `var foo = require('src/foo')`
>> > >
>> > > Not a huge win over just using relative paths so meh.
>> > >
>> > > I don't understand why instanceof wouldn't work?
>> > >
>> >
>> > You probably have a better understanding of this than I do... But:
>> > - There's no problem when running locally, since we've defined the
>> > structure of node_modules to work,
>> >
>> > But when npm install is run on an end-users machine, if it ends up like:
>> >
>> > cordova-lib/node_modules/cordova-plugman/node_modules/CordovaError
>> > cordova-lib/node_modules/cordova-cli/node_modules/CordovaError
>> > cordova-lib/node_modules/CordovaError
>> >
>> > then there are now 3 CordovaError constructors, so instanceof will not
>> work
>> > between them.
>> >
>> > Now, if npm sees that all packages call for the same version of
>> > CordovaError, and install them like:
>> >
>> > cordova-lib/node_modules/cordova-plugman
>> > cordova-lib/node_modules/cordova-cli
>> > cordova-lib/node_modules/CordovaError
>> >
>> > then all is well.
>> >
>> > Easy to answer with a quick test :)
>> >
>> >
>> >
>> > >
>> > >
>> > > On Fri, Jun 6, 2014 at 9:14 AM, Andrew Grieve 
>> > > wrote:
>> > >
>> > > > Exciting! I tried the "check in node_modules" approach in
>> > > > cordova-app-harness and it works really well there:
>> > > >
>> https://github.com/apache/cordova-app-harness/tree/master/harness-push
>> > > > It's a simpler case since there's a strict parent/child relationship.
>> > > >
>> > > > The main unknown for me is how to make CordovaError work as its own
>> > > module
>> > > > since we'll require that there is never multiple copies of the module
>> > > when
>> > > > the end-user types "npm install" (or else the instanceof check won't
>> > > work).
>> > > > I *think* that npm does the right thing so long as all of the
>> packages
>> > > use
>> > > > the same version constraints for it, but I haven't tested it.
>> > > >
>> > > >
>> > > > On Fri, Jun 6, 2014 at 11:37 AM, Michal Mocny 
>> > > wrote:
>> > > >
>> > > > > Brian: sounds good.  Looking forward to see where we get.
>> > > > >
>> > > > > -Michal
>> > > > >
>> > > > >
>> > > > > On Fri, Jun 6, 2014 at 11:36 AM, Brian LeRoux  wrote:
>> > > > >
>> > > > > > @Michal: we're going to start extracting things to their own
>> > modules.
>> > > > (As
>> > > > > > discussed.) We're going to start small and simple: CordovaError,
>> > > > > > SuperSpawn, etc. But before we do that we'll try to merge up as
>> > many
>> > > > PRs
>> > > > > as
>> > > > > > possible. Ideally there are none when we get rolling. (Next
>> week.)
>> > > > > >
>> > > > > > Many repos (or just small modules) would isolate the changes
>> making
>> > > it
>> > > > > > easier to refactor. Anyhow: I'm tired of advocating that design
>> > > pattern
>> > > > > > choice and I'm sure you're tired of hearing about it!
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Jun 5, 2014 at 6:04 PM, Michal Mocny <
>> mmo...@chromium.org>
>> > > > > wrote:
>> > > > > >
>> > > > > > > On Thu, Jun 5, 2014 at 6:47 PM, Brian LeRoux 
>> wrote:
>> > > > > > >
>> > > > > > > > we're about to do some heavy refactoring on c

Re: Plugin release

[Lorin Beer]

I volunteer Steve!

On Tue, May 27, 2014 at 5:05 PM, Steven Gill  wrote:
> Good idea. I need to merge some PRs in before we move forward. Any
> volunteers for being the release master :P
>
>
> On Tue, May 27, 2014 at 3:54 PM, Jesse  wrote:
>
>> I think we have a bunch of plugin updates that need to be pushed out.
>> Can we aim for later this week to do a plugin release for repos with
>> updates?
>>
>>
>>
>> @purplecabbage
>> risingj.com
>>

Re: Many CLI tests failing

[Lorin Beer]

Thanks Max,

took a look, some tests for functionality that isn't implemented made it
into master. I've reverted the offending change.

As policy, I'm behind reverting any commit that fails tests or breaks
functionality. It pollutes everyone's dev process with issues that should
remain isolated. I say this as one of the guilty parties this time.


- Lorin


On Tue, Mar 25, 2014 at 6:36 PM, Max Woghiren  wrote:

> Josh is having trouble accessing the buildbot page, so here is the
> relevant information.
>
> Lorin's relevant commit:
>
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=79e571953c2d3459b459c02eb50e753308fd453d
>
> Josh's relevant commits:
>
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=07181e4ee3e358b7af7674a4ae68fe06552b2655(platform
>  parsers)
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=edecaf9193e8b23c6b7e209c6893491497021082(create.js)
>
> Lorin's commit led to errors 2-5.  The remainder are the result of Josh's
> commits.
>
> The text of the failed tests:
>
> 1) hooker should throw if provided directory is not a cordova project
>Message:
>   [31mExpected function to throw Not a Cordova project, can't use hooks. 
> , but it threw Not a Cordova project 
> ("/var/folders/p5/b_w_jqzj2jd64nz22dnv7xzcgn/T/e2e-test/hooks_test"), 
> can't use hooks. [0m
>Stacktrace:
>  Error: Expected function to throw Not a Cordova project, can't use 
> hooks. , but it threw Not a Cordova project 
> ("/var/folders/p5/b_w_jqzj2jd64nz22dnv7xzcgn/T/e2e-test/hooks_test"), 
> can't use hooks.
> at null. 
> (/Users/medic/buildbot/slave_common/Tools_CLI/build/cordova-cli/e2e/hooker.spec.js:53:12)
>
>   2) create command callback should return null if a callback parameter is 
> used
>Message:
>   [31mReferenceError: foobar is not defined [0m
>Stacktrace:
>  ReferenceError: foobar is not defined
> at null. 
> (/Users/medic/buildbot/slave_common/Tools_CLI/build/cordova-cli/spec/create.spec.js:79:66)
>
>   3) create command callback should return null if a callback parameter is 
> used
>Message:
>   [31mtimeout: timed out after 1 msec waiting for something to happen 
> [0m
>Stacktrace:
>  undefined
>
>   4) create command callback should call the callback function if callback 
> parameter is used
>Message:
>   [31mReferenceError: foobar is not defined [0m
>Stacktrace:
>  ReferenceError: foobar is not defined
> at null. 
> (/Users/medic/buildbot/slave_common/Tools_CLI/build/cordova-cli/spec/create.spec.js:79:66)
>
>   5) create command callback should call the callback function if callback 
> parameter is used
>Message:
>   [31mtimeout: timed out after 1 msec waiting for something to happen 
> [0m
>Stacktrace:
>  undefined
>
>   6) create command success should create top-level directory structure 
> appropriate for a cordova-cli project
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete [0m
>Stacktrace:
>  undefined
>
>   7) create command success should create hooks directory
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete [0m
>Stacktrace:
>  undefined
>
>   8) create command success should by default use cordova-app-hello-world as 
> www assets
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete [0m
>Stacktrace:
>  undefined
>
>   9) create command success should try to lazy load custom www location if 
> specified
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete [0m
>Stacktrace:
>  undefined
>
>   10) create command success should add a missing www/config.xml
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete [0m
>Stacktrace:
>  undefined
>
>   11) create command success should not replace an existing www/config.xml
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete [0m
>Stacktrace:
>  undefined
>
>   12) android project parser constructions should throw if provided directory 
> does not contain an AndroidManifest.xml
>Message:
>   [31mExpected function to throw The provided path "some/path" is not an 
> Android project. , but it threw CordovaError is not defined [0m
>Stacktrace:
>  Error: Expected function to throw The provided path "some/path" is not 
> an Android project. , but it threw CordovaError is not defined
> at null. 
> (/Users/medic/buildbot/slave_common/Tools_CLI/build/cordova-cli/spec/metadata/android_parser.spec.js:71:16)
>
>   13) blackberry10 project parser constructions should throw an exception 
> with a path that is not a native blackberry project
>Message:
>   [31mExpected function to throw The provided path "/some/path" is not a 
> Cordova BlackBerry10 project. , but it threw CordovaError is not defin

Re: Introduction

[Lorin Beer]

Hi Staci, welcome onboard!


On Mon, Mar 17, 2014 at 11:00 AM, Staci Cooper  wrote:

> Hello all,
>
> I've been watching the dev list for a while, and now I'd like to introduce
> myself. I've recently joined the Cordova team at IBM. As a long time user
> and supporter of open source, I'm happy to start contributing back and very
> excited to be working on this project.
>
> I will be working with the Windows 8, Windows Phone 8, and Blackberry
> platforms. I look forward to collaborating with and learning from this
> group!
>
> Best,
> Staci Cooper
> 
> 
>

minor cli upgrade

[Lorin Beer]

with the upgrade to promises some time ago, projects which rely on the
Cordova CLI had to adjust how they interacted with the cdv cli api.

I've come across several js libraries that support both and imho this would
be a great addition to the cordova cli, and would provide a cleaner and
more stable surface area to interact with.

The api change is simple, and non-breaking. If a callback argument is
provided, no promise is returned and the callback is executed. If the
callback argument cannot be resolved, a promise is returned.

I'll be pursuing this minor upgrade today, please leave any feedback if
you're interested.

- Lorin

Re: Release Managers

[Lorin Beer]

+1 + i


On Mon, Mar 17, 2014 at 7:37 AM, Ian Clelland wrote:

> +1, this is a good idea.
>
>
> On Thu, Mar 13, 2014 at 12:44 PM, Michal Mocny 
> wrote:
>
> > +1, like the idea of putting your name into a hat.
> >
> > How about "coaching" the first time someone does a release?  Do we prefer
> > to let the docs stand for themselves?
> >
>
> Coaching is definitely a good idea as well; or something like it. However,
> making sure that the docs are up to date and usable should be an important
> part of being RM.
>
> It should't be an onerous thing -- just "if there's a step missing, or
> something that wouldn't have worked, then fix the docs for the next guy".
>
> Ian
>
>
> >
> > -Michal
> >
> >
> > On Thu, Mar 13, 2014 at 11:13 AM, Andrew Grieve  > >wrote:
> >
> > > I'd previously brought up the idea of "Release Masters", and now after
> > the
> > > recent highlight of our release process by other Apache project
> members,
> > > I've learned that they are common, and are actually called "Release
> > > Managers".
> > >
> > > Their role, in a nutshell, is to take ownership of a release (either
> > > through delegation, or by doing it themselves).
> > >
> > > It's generally not a glorious job, so it would be great if we could do
> a
> > > bit of a rotation on it:
> > > - a rotation for tools,
> > > - a rotation for plugins,
> > > - a rotation for platforms release.
> > >
> > > For tools & plugins, the responsibility is a bit better defined I
> think -
> > > they are responsible for going through the steps in the release
> process.
> > >
> > > For platform releases, the release manager wouldn't necessarily be
> > > responsible for individual platforms, but rather for things like docs,
> > > website, dist/, and for poking people.
> > >
> > >
> > > As for a rotation, one thought is to write down the names of those
> > willing
> > > in the actual release steps .md files, and then they can plan out how
> to
> > > schedule themselves from there.
> > >
> > > How does this sound?
> > >
> >
>

Re: 3.4.0-x.x.x inaccessible through 'npm install cordova'

[Lorin Beer]

Thanks Carlos,

it's a definite possibility, but due to all the npm troubles, I wiped my
npm cache.


On Tue, Mar 4, 2014 at 2:13 PM, Carlos Santana  wrote:

> yes blame npm take the easy route out :-)
>
> One thing it could be is that npm failed to fetch latest from npm registry
> (possible related to their ssl certificate issue [1]) and installed from
> your npm cache.
>
> One tip to troubleshoot installations problems with npm, is to clean your
> cache
> npm cache clean cordova
> or
> rm -rf ~/.npm/cordova
>
>
>
> [1]:
>
> http://blog.npmjs.org/post/78165272245/more-help-with-self-signed-cert-in-chain-and-npm
>
>
> On Tue, Mar 4, 2014 at 2:08 PM, Michal Mocny  wrote:
>
> > ..last week I saw 0.1.1 published under the rc, even hours after Andrew
> > claimed to release 0.1.2.  I figured it was me/him who made a mistake,
> but
> > given everything, and that npm have been blogging about all sorts of
> > quirks.. yes, blame canad^H^H^H^H^H npm.
> >
> > -Michal
> >
> >
> > On Tue, Mar 4, 2014 at 2:00 PM, Lorin Beer 
> > wrote:
> >
> > > I'm blaming npm for this.
> > >
> > > With 1.4.4, I am now getting 0.1.2, the rc, instead of 0.1.0.
> > >
> > > Evidently not our issue, so ignore my "unpublish" suggestion.
> > >
> > >
> > > On Mon, Mar 3, 2014 at 4:48 PM, Carlos Santana 
> > > wrote:
> > >
> > > > I just tried with npm 1.4.3 (version included with v0.10.26)
> > > > I got:
> > > >
> > > > $ npm install -g cordova
> > > >
> > > > $ npm ls -g cordova
> > > >
> > > > /Users/csantana23/.nvm/v0.10.26/lib
> > > >
> > > > └── cordova@3.4.0-0.1.0
> > > >
> > > > When I do "npm view cordova" I see this
> > > >
> > > > { name: 'cordova',
> > > >
> > > >   description: 'Cordova command line interface tool',
> > > >
> > > >   'dist-tags': { latest: '3.4.0-0.1.0', rc: '3.4.0-0.1.2' },
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Mar 3, 2014 at 6:11 PM, Lorin Beer  >
> > > > wrote:
> > > >
> > > > > Weird, that still isn't the latest version.
> > > > >
> > > > > what version of npm did you use? I'm running 1.4.4
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Mar 3, 2014 at 3:08 PM, Steven Gill <
> stevengil...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > hmm, I just did a npm install cordova and got 3.4.0-0.1.0
> > > > > >
> > > > > >
> > > > > > On Mon, Mar 3, 2014 at 2:56 PM, Lorin Beer <
> > lorin.beer@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Currently, the 3.4.0-rc.2 release currently resolves as
> 'higher'
> > > than
> > > > > the
> > > > > > > actual 3.4.0 releases: '3.4.0-0.1.0', '3.4.0-0.1.1', and
> > > > '3.4.0-0.1.2',
> > > > > > >
> > > > > > > you can check this with:
> > > > > > >
> > > > > > > $ npm view cordova versions
> > > > > > >
> > > > > > > This means that $ npm install cordova installs rc2 instead of
> the
> > > > > latest
> > > > > > > 3.4.0 release.
> > > > > > >
> > > > > > > I suggest unpublishing the current rc2 tag and renaming it.
> > > > > > >
> > > > > > > - Lorin
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Carlos Santana
> > > > 
> > > >
> > >
> >
>
>
>
> --
> Carlos Santana
> 
>

Re: 3.4.0-x.x.x inaccessible through 'npm install cordova'

[Lorin Beer]

I'm blaming npm for this.

With 1.4.4, I am now getting 0.1.2, the rc, instead of 0.1.0.

Evidently not our issue, so ignore my "unpublish" suggestion.


On Mon, Mar 3, 2014 at 4:48 PM, Carlos Santana  wrote:

> I just tried with npm 1.4.3 (version included with v0.10.26)
> I got:
>
> $ npm install -g cordova
>
> $ npm ls -g cordova
>
> /Users/csantana23/.nvm/v0.10.26/lib
>
> └── cordova@3.4.0-0.1.0
>
> When I do "npm view cordova" I see this
>
> { name: 'cordova',
>
>   description: 'Cordova command line interface tool',
>
>   'dist-tags': { latest: '3.4.0-0.1.0', rc: '3.4.0-0.1.2' },
>
>
>
>
>
>
> On Mon, Mar 3, 2014 at 6:11 PM, Lorin Beer 
> wrote:
>
> > Weird, that still isn't the latest version.
> >
> > what version of npm did you use? I'm running 1.4.4
> >
> >
> >
> >
> > On Mon, Mar 3, 2014 at 3:08 PM, Steven Gill 
> > wrote:
> >
> > > hmm, I just did a npm install cordova and got 3.4.0-0.1.0
> > >
> > >
> > > On Mon, Mar 3, 2014 at 2:56 PM, Lorin Beer 
> > > wrote:
> > >
> > > > Currently, the 3.4.0-rc.2 release currently resolves as 'higher' than
> > the
> > > > actual 3.4.0 releases: '3.4.0-0.1.0', '3.4.0-0.1.1', and
> '3.4.0-0.1.2',
> > > >
> > > > you can check this with:
> > > >
> > > > $ npm view cordova versions
> > > >
> > > > This means that $ npm install cordova installs rc2 instead of the
> > latest
> > > > 3.4.0 release.
> > > >
> > > > I suggest unpublishing the current rc2 tag and renaming it.
> > > >
> > > > - Lorin
> > > >
> > >
> >
>
>
>
> --
> Carlos Santana
> 
>

Re: [Vote] cordova@3.4.0-0.1.3 plugman@0.20.2

[Lorin Beer]

+1


On Tue, Mar 4, 2014 at 6:48 AM, Michal Mocny  wrote:

> +1
>
>
> On Tue, Mar 4, 2014 at 8:05 AM, Bryan Higgins  >wrote:
>
> > +1
> >
> >
> > On Mon, Mar 3, 2014 at 9:48 PM, Ian Clelland 
> > wrote:
> >
> > > +1
> > >
> > > Tested from dist.apache.org, verified code matching hashes, signature
> > and
> > > repositories. Verified CB-6151 fix.
> > >
> > >
> > > On Mon, Mar 3, 2014 at 4:25 PM, Andrew Grieve 
> > > wrote:
> > >
> > > > Please review and vote on this Tools Release.
> > > >
> > > > These archives are identical to cordova@3.4.0-0.1.2plugman@0.20.1with
> > > > the
> > > > exception of the fix for CB-6151.
> > > >
> > > > Release issue: https://issues.apache.org/jira/browse/CB-6115
> > > >
> > > > Both tools have been published to dist/dev:
> > > > https://dist.apache.org/repos/dist/dev/cordova/CB-6115/
> > > >
> > > > The packages were published from their corresponding git tags:
> > > > cordova-plugman: 0.20.2 (f1b206d02a)
> > > > cordova-cli: 3.4.0-0.1.3 (0f6250fa3d)
> > > >
> > > > Upon a successful vote I will upload the archives to dist/, publish
> > them
> > > to
> > > > NPM, and post the corresponding blog post.
> > > >
> > > > Voting will go on for a minimum of 24 hours.
> > > >
> > > > I vote +1.
> > > >
> > > > Note that this time, I have not uploaded them to NPM. Want to avoid
> > > having
> > > > to bump the version number again. Please install them from dist/ or
> > from
> > > > the git tag.
> > > >
> > >
> >
>

Re: 3.4.0-x.x.x inaccessible through 'npm install cordova'

[Lorin Beer]

Weird, that still isn't the latest version.

what version of npm did you use? I'm running 1.4.4




On Mon, Mar 3, 2014 at 3:08 PM, Steven Gill  wrote:

> hmm, I just did a npm install cordova and got 3.4.0-0.1.0
>
>
> On Mon, Mar 3, 2014 at 2:56 PM, Lorin Beer 
> wrote:
>
> > Currently, the 3.4.0-rc.2 release currently resolves as 'higher' than the
> > actual 3.4.0 releases: '3.4.0-0.1.0', '3.4.0-0.1.1', and '3.4.0-0.1.2',
> >
> > you can check this with:
> >
> > $ npm view cordova versions
> >
> > This means that $ npm install cordova installs rc2 instead of the latest
> > 3.4.0 release.
> >
> > I suggest unpublishing the current rc2 tag and renaming it.
> >
> > - Lorin
> >
>

3.4.0-x.x.x inaccessible through 'npm install cordova'

[Lorin Beer]

Currently, the 3.4.0-rc.2 release currently resolves as 'higher' than the
actual 3.4.0 releases: '3.4.0-0.1.0', '3.4.0-0.1.1', and '3.4.0-0.1.2',

you can check this with:

$ npm view cordova versions

This means that $ npm install cordova installs rc2 instead of the latest
3.4.0 release.

I suggest unpublishing the current rc2 tag and renaming it.

- Lorin

Re: Voting on past releases

[Lorin Beer]

Sebb,

I've noticed in multiple posts from you a deep confusion over how our
project operates.

To avoid generating unhelpful noise on our list and in the middle of
important discussions, I would respectfully suggest you follow some of the
links Joe Bowser has posted and educate yourself on how our project
operates and generates the releases.

- Lorin


On Tue, Feb 25, 2014 at 2:37 PM, sebb  wrote:

> On 25 February 2014 21:47, Michal Mocny  wrote:
> > Some tips, since I found this a pain to figure out.  To verify the sha
> file
> > matches:
> >
> >> gpg --print-md SHA512 *.zip | diff - *.sha && echo "Exact match"
> >> gpg --print-md MD5 *.zip | diff - *.md5 && echo "Exact match"
> >
> > Oddly the output of gpg is different than that of sha512sum and md5sum so
> > you cannot use those commands to --check the sums, ugh.  (We should
> > consider changing the way we generate those files, no?).
> >
> > I'm still trying to figure out how to make sure the zip is signed
> > correctly, but am having issues setting up my KEYS.
> >
> > All-in-all I don't think this is that useful of a process to do, since to
> > be really confident you would have to create the full release zip from
> > scratch from source control yourself and compare *that* to the hosted zip
> > to make sure we releasing what you think we are (as is we are just
> > verifying the download isn't corrupt).  But I wanted to go through the
> > process.
>
> I thought the idea was to compare the released zip with the source repo?
> i.e. unpack the release, and compare it with the contents of the tags
> in the repo.
>
> If all the files in the release zip have exact matches in a repo tag,
> then the release zip must be OK .
>
> If any zip files are missing from the repo, then this is a potential
> problem from the point of view of whether the file is suitably
> licensed.
>
> If repo files are missing from the zip, then perhaps there was an
> error creating the release.
> For a past release, that is not an issue - but of course it may be
> necessary to fix the process for the future.
>
> >
> >
> > On Tue, Feb 25, 2014 at 3:33 PM, Lorin Beer  >wrote:
> >
> >> I've just submitted my +1 for a number of the past releases, and thought
> >> I'd document here what the steps I took were.
> >>
> >> Since these are past releases, some of which I helped tag and have
> already
> >> run, the checklist is slightly simplified:
> >>
> >> - download package
> >> - sanity check package for expected release artifacts
> >> - tags are correct
> >> - commit hash matches the source
> >>
> >>
> >> On Tue, Feb 25, 2014 at 11:35 AM, Steven Gill  >> >wrote:
> >>
> >> > It has been brought to our attention that some of our previous
> releases
> >> > were not voted on in accordance with the ASF by-laws. After some
> >> > discussion, we've decided to call a retroactive vote on these
> releases. A
> >> > vote is being conducted by the PMC and the results will be posted here
> >> when
> >> > complete.
> >> >
> >>
>

Re: [VOTE] Cordova 3.3.0

[Lorin Beer]

+1


On Tue, Feb 25, 2014 at 1:49 PM, Joe Bowser  wrote:

> +1
>
> On Tue, Feb 25, 2014 at 12:27 PM, Steven Gill 
> wrote:
> > Please review and vote on our past release of Cordova 3.3.0.
> >
> > You can find the src + asc + md5 + sha at the following links:
> > * http://archive.apache.org/dist/cordova/cordova-3.3.0-src.zip
> > * http://archive.apache.org/dist/cordova/cordova-3.3.0-src.zip.asc
> > * http://archive.apache.org/dist/cordova/cordova-3.3.0-src.zip.md5
> > * http://archive.apache.org/dist/cordova/cordova-3.3.0-src.zip.sha
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/3.3.0
> > 97ad4d84ce333f05d6240b75f65da8536bcc3eb1 refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/3.3.0
> > 4972510ca591f8756a0a6b756c0d6691976e2106 refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/3.3.0
> > ac5f461fabd598271b4a6bdeb5b57018e2cb5e61 refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/3.3.0
> > b92941c90ff2f3a99d77e77bfa334a7d2c74f534 refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/3.3.0
> > 68de03b36dd32d3707b9cdf6ef050bbe87343a48 refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-firefoxos.git;a=shortlog;h=refs/tags/3.3.0
> > 02b07dfe0115e4ce92e494c6c43ba882a5564b26 refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-ubuntu.git;a=shortlog;h=refs/tags/3.3.0
> > c477479a8ddccb4c1a2e2630e5300c1629ebe94c refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-amazon-fireos.git;a=shortlog;h=refs/tags/3.3.0
> > e9d39c53c448905eacfefed00dbb3af82a3856d6 refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/3.3.0
> > b7feb74d4e72d2b759350433286d88d50fc59be7 refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/3.3.0
> > 86d912c7c6938c6b936183a2e8b30e1638906242 refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/3.3.0
> > 01af7dca35ff413b9fbb4e24b664861f6f45731b refs/tags/3.3.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/3.3.0
> > c6219cfc76e070df7ddc0a79b97e99ef856e86c6 refs/tags/3.3.0
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/3.3.0-0.1.0
> > f338c0fc6f2ccc09b48001e96dd80d15757c8e83 refs/tags/3.3.0-0.1.0
> >
> > Voting will go on for 48 hours.
>

Re: [VOTE] Cordova 3.2.0

[Lorin Beer]

+1


On Tue, Feb 25, 2014 at 1:44 PM, Joe Bowser  wrote:

> +1
>
> (The notorious JAVA_HOME bug is in here. Damn you Maven!!! DAMN YOU!!!)
>
> On Tue, Feb 25, 2014 at 12:24 PM, Steven Gill 
> wrote:
> > Please review and vote on our past release of Cordova 3.2.0.
> >
> > You can find the src + asc + md5 + sha at the following links:
> > * http://archive.apache.org/dist/cordova/cordova-3.2.0-src.zip
> > * http://archive.apache.org/dist/cordova/cordova-3.2.0-src.zip.asc
> > * http://archive.apache.org/dist/cordova/cordova-3.2.0-src.zip.md5
> > * http://archive.apache.org/dist/cordova/cordova-3.2.0-src.zip.sha
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/3.2.0
> > 221b10b1e6a94f5739f8795a679ea019c8b9343e refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/3.2.0
> > 6874642dda11d792a6ccb9cd861b36b73fc45aa8 refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/3.2.0
> > 3f92336a1510985c90b05130429c20bcd43e6895 refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/3.2.0
> > 02b49166061bcb7f3d663e79752c7aab29b07afe refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/3.2.0
> > 073240e430198c6b266ecaf6800b75ac6b7ba6ab refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-firefoxos.git;a=shortlog;h=refs/tags/3.2.0
> > 1091597a346e0debd6e5f4fc3e756973dce7e995 refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-ubuntu.git;a=shortlog;h=refs/tags/3.2.0
> > 0a2e2476d69373dabc7452b4225ffd18dfb96fca refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-amazon-fireos.git;a=shortlog;h=refs/tags/3.2.0
> > b3b7c0b9dbaa6017e7e78c59d06300360454f90b refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/3.2.0
> > fc683fbb04846ea54c8a173b9ad59361662f4c56 refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/3.2.0
> > dfca43fd78c8cba06f88b67a5649e953a2b2795f refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/3.2.0
> > ee9a8632247a23339221c7d894b7bd617bf39d2e refs/tags/3.2.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/3.2.0
> > 3ef0092b0c940855990102a50a905dc19241adeb refs/tags/3.2.0
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/3.2.0-0.1.0
> > d7fde3ffca2feaf55cf064d19e5bfc90df398e71 refs/tags/3.2.0-0.1.0
> >
> > Voting will go on for 48 hours.
>

Re: [VOTE] Cordova 3.1.0

[Lorin Beer]

+1


On Tue, Feb 25, 2014 at 1:37 PM, Joe Bowser  wrote:

> +1
>
> On Tue, Feb 25, 2014 at 12:21 PM, Steven Gill 
> wrote:
> > Please review and vote on our past release of Cordova 3.1.0.
> >
> > You can find the src + asc + md5 + sha at the following links:
> > * http://archive.apache.org/dist/cordova/cordova-3.1.0-src.zip
> > * http://archive.apache.org/dist/cordova/cordova-3.1.0-src.zip.asc
> > * http://archive.apache.org/dist/cordova/cordova-3.1.0-src.zip.md5
> > * http://archive.apache.org/dist/cordova/cordova-3.1.0-src.zip.sha
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/3.1.0
> > e5b01579711e845c34e80b91bd1005a6d0205451 refs/tags/3.1.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/3.1.0
> > bbc04638e38a2978d05d8178c2d78d9b4406bdc4 refs/tags/3.1.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/3.1.0
> > c60b4a44e4df33523c1f70bc8432c8aab5a0c371 refs/tags/3.1.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/3.1.0
> > 0ca3a25e9b092e5446f29f20f37d8f808df8e49a refs/tags/3.1.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/3.1.0
> > 0b539a85bd390f78f9bb95f57c8536bed84dd726 refs/tags/3.1.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-firefoxos.git;a=shortlog;h=refs/tags/3.1.0
> > 129489d8160bc4397c6d71660534cb40192f88f8 refs/tags/3.1.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/3.1.0
> > 1517b704704016e408f29b1326a5b94dc39b2399 refs/tags/3.1.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/3.1.0
> > a7cebd57660348baf28d8936a2187f10373a5337 refs/tags/3.1.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/3.1.0
> > 5683220ad99ea3e879b742b6eb7ecb42d9c79698 refs/tags/3.1.0
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/3.1.0
> > 1a73cb7147e6229681db8788fb1022c2f98b45e6 refs/tags/3.1.0
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/3.1.0-0.1.0
> > f346be0c4221a6dfba909d154cddcbf6ba843542 refs/tags/3.1.0-0.1.0
> >
> > Voting will go on for 48 hours.
>

Re: Voting on past releases

[Lorin Beer]

I've just submitted my +1 for a number of the past releases, and thought
I'd document here what the steps I took were.

Since these are past releases, some of which I helped tag and have already
run, the checklist is slightly simplified:

- download package
- sanity check package for expected release artifacts
- tags are correct
- commit hash matches the source


On Tue, Feb 25, 2014 at 11:35 AM, Steven Gill wrote:

> It has been brought to our attention that some of our previous releases
> were not voted on in accordance with the ASF by-laws. After some
> discussion, we've decided to call a retroactive vote on these releases. A
> vote is being conducted by the PMC and the results will be posted here when
> complete.
>

Re: [VOTE] Cordova 3.0.0

[Lorin Beer]

+1


On Tue, Feb 25, 2014 at 12:17 PM, Steven Gill wrote:

> Please review and vote on our past release of Cordova 3.0.0.
>
> You can find the src + asc + md5 + sha at the following links:
> * http://archive.apache.org/dist/cordova/cordova-3.0.0-src.zip
> * http://archive.apache.org/dist/cordova/cordova-3.0.0-src.zip.asc
> * http://archive.apache.org/dist/cordova/cordova-3.0.0-src.zip.md5
> * http://archive.apache.org/dist/cordova/cordova-3.0.0-src.zip.sha
>
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/3.0.0
> d0b3f419efb0e364879b79139936a1a8a9ff6459 refs/tags/3.0.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/3.0.0
> 26df4e23076c91dfc048b1a52b1a1ffa8963b6cd refs/tags/3.0.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/3.0.0
> 3b791ff310ca944aa57afd71c462998cb36f9c80 refs/tags/3.0.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/3.0.0
> 7055d60fbd320f8c31a9942032057977bb51b2fd refs/tags/3.0.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/3.0.0
> 1ef8f6a0a6431930f5c9826d3c315e99d9194371 refs/tags/3.0.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/3.0.0
> 40979c6789b29e43470737673a8476d94e57f086 refs/tags/3.0.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/3.0.0
> e670de91e68b2bf08f04b05cf997305f4bc3d4b1 refs/tags/3.0.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/3.0.0
> e12609d87241d57113ac27399a2061798a8ecd88 refs/tags/3.0.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/3.0.0
> c9fb07b84401da76dc805d2a550ca5c77dc03457 refs/tags/3.0.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/3.0.0
> 52e16d09b3eae6eda94927ce8e9ea3145cff211a refs/tags/3.0.0
>
> Voting will go on for 48 hours.
>

Re: [Vote] Cordova 2.9.1

[Lorin Beer]

+1


On Tue, Feb 25, 2014 at 12:14 PM, Steven Gill wrote:

> Please review and vote on our past release of Cordova 2.9.1.
>
> You can find the src + asc + md5 + sha at the following links:
> * http://archive.apache.org/dist/cordova/cordova-2.9.1-src.zip
> * http://archive.apache.org/dist/cordova/cordova-2.9.1-src.zip.asc
> * http://archive.apache.org/dist/cordova/cordova-2.9.1-src.zip.md5
> * http://archive.apache.org/dist/cordova/cordova-2.9.1-src.zip.sha
>
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/2.9.1
> 2a68fd4394f78ad17d05debe34a37296f218df10 refs/tags/2.9.1
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/2.9.1
> 0f79933977213ed32f75690edfb1edcde679fcbe refs/tags/2.9.1
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/2.9.1
> 62f3d3025cb5f34bdb7bd8fa07bffce86d263f21 refs/tags/2.9.1
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/2.9.1
> 10af4e40ad45889029766fa08aa0614332ea1071 refs/tags/2.9.1
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/2.9.1
> 9d8009021083e063a7fd2280aebd3734d8d03843 refs/tags/2.9.1
>
> Blackberry used 2.9.0 tag.
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/2.9.0
> b98007cba30c3e4017671e10d7c8f463ddb87855 refs/tags/2.9.0
>
> Voting will go on for 48 hours.
>

Re: [VOTE] Cordova 2.9.0

[Lorin Beer]

+1


On Tue, Feb 25, 2014 at 12:08 PM, Steven Gill wrote:

> Please review and vote on our past release of Cordova 2.9.0.
>
> You can find the src + asc + md5 + sha at the following links:
> * http://archive.apache.org/dist/cordova/cordova-2.9.0-src.zip
> * http://archive.apache.org/dist/cordova/cordova-2.9.0-src.zip.asc
> * http://archive.apache.org/dist/cordova/cordova-2.9.0-src.zip.md5
> * http://archive.apache.org/dist/cordova/cordova-2.9.0-src.zip.sha
>
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/2.9.0
> df1536ea77e97b7d362a19582f8beddd168c5ec3 refs/tags/2.9.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/2.9.0
> 00e62aad4244ceac1f19193b1e0f2396f1ca41d9 refs/tags/2.9.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/2.9.0
> b98007cba30c3e4017671e10d7c8f463ddb87855 refs/tags/2.9.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/2.9.0
> 47fe25f3ad058515c0a309fbdbdb4ce0960052f4 refs/tags/2.9.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/2.9.0
> 770951b10de09419c8e3a223468e90c85f25adb7 refs/tags/2.9.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/2.9.0
> 87db44d7ab3f952ba62501dbb8f47aa6356c8658 refs/tags/2.9.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/2.9.0
> 83dc4bd9010447ea9b93889481516c64a9a46cde refs/tags/2.9.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/2.9.0
> 4cb28c7c511bfd677c5ab4a569ebf34657b4ef6a refs/tags/2.9.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/2.9.0
> 64da512386af1248ca77262053ee8b2c3a99428b refs/tags/2.9.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/2.9.0
> a71389b6351a1b237cd1f171f674c8f62a9e0778 refs/tags/2.9.0
>
> Voting will go on for 48 hours.
>

Re: [VOTE] Cordova 2.8.1

[Lorin Beer]

+1


On Tue, Feb 25, 2014 at 12:03 PM, Steven Gill wrote:

> Please review and vote on our past release of Cordova 2.8.1.
>
> You can find the src + asc + md5 + sha at the following links:
> * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip
> * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip.asc
> * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip.md5
> * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip.sha
>
> The 2.8.1 tag was only applied to Android
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/2.8.1
> d8c755b95a85de95c51768a271aa2747bb5467b9 refs/tags/2.8.1
>
> The 2.8.0 tag was used for other platforms
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/2.8.0
> f93f7a5bad8b7f9d141852c8b1f369a262f0389e refs/tags/2.8.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/2.8.0
> a297ff557b93c30427a113af80620221c8a74f40 refs/tags/2.8.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/2.8.0
> 326130a182e5cd2d391e942efdf961cc6fa34040 refs/tags/2.8.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/2.8.0
> 9176a0238c26ea1fd5edfe2e2b052607aca1b9ac refs/tags/2.8.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/2.8.0
> a2f158653f533ebbb5dfbfe136bfdf9e1a57f01c refs/tags/2.8.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/2.8.0
> 6208c9593a0a472f3e04168c9d237a3121329c1a refs/tags/2.8.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/2.8.0
> 4fdfaad8fed1ea52bea5401ee1e1d2099d94f446 refs/tags/2.8.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/2.8.0
> 366f9843eb3d2172986d18cf370323ddd35117b8 refs/tags/2.8.0
>
> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/2.8.0
> c222b586d286d2dd3a7ba67259d05d5f60e51d8f refs/tags/2.8.0
>
> Voting will go on for 48 hours.
>

Re: Dropping iOS 5.0 support

[Lorin Beer]

+1


On Fri, Feb 7, 2014 at 7:58 AM, Emil Marashliev  wrote:

>
> On Feb 7, 2014, at 5:00 PM, James Jong  wrote:
>
> > Ally,
> > Have you seen this (iOS 5 %) in your other apps as well?  Or more so for
> the new releases?
> > -James Jong
> >
> > On Feb 5, 2014, at 10:32 PM, Ally Ogilvie  wrote:
> >
> >> Bump.
> >>
> >> Didn't see a solid statement here but...
> >>
> >> As a developer for the commercial machine we launched a game in Asia Q4
> >> 2013 and with a now sizeable amount of users: iOS 5.1 is 1% of total
> users.
> >>
> >> +1 drop support for version < 6.0.
> >>
> >>
> >>
> >>
> >> On Sat, Dec 21, 2013 at 10:02 AM, Shazron  wrote:
> >>
> >>> I think that last paragraph is key - let's provide instructions in a
> doc in
> >>> cordova-ios/guides if they need this support. Not sure we need this in
> >>> cordova-docs
> >>>
> >>>
> >>> On Fri, Dec 20, 2013 at 6:15 AM, Andrew Grieve 
> >>> wrote:
> >>>
>  I think we'd be fine to drop "official support" for iOS 5, but as has
> >>> been
>  pointed out, there's very little code-wise that would change.
> 
>  If bug reports come that say "this function is being called and it
> >>> doesn't
>  exist on iOS 5", then that's a trivial fix. Likely devs will just fix
> it
>  themselves anyways.
> 
>  If devs want to deploy for iOS 5, I think they'll be able to fiddle
> with
>  their Xcode deployment target settings and do so fairly easily even
> if we
>  "drop support for it". They are better at testing their own apps
> anyways.
> 
> 
> 
> 
> 
>  On Fri, Dec 20, 2013 at 7:00 AM, Josh Soref 
> >>> wrote:
> 
> > Fwiw, If you have your installation media, getting 10.8/10.9 to
> install
>  in
> > the latest version of VirtualBox is trivial. I believe that the same
> > applies to 10.7, but I can't find my installation media :(.
> > -
> > 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.
> >
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Ally Ogilvie
> >> Lead Developer - MobDev. | Wizcorp Inc. 
> >> --
> >> TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 |
> >> Website
> >> | Twitter  |
> >> Facebook
> >> | LinkedIn 
> >
>
>
> +1
>
>
>

Re: Introducing myself

[Lorin Beer]

Hi Martin, welcome!


On Tue, Feb 4, 2014 at 12:52 PM, Brian LeRoux  wrote:

> Welcome Martin! Glad to have you here and feel free to bug the list for
> help anytime. =)
>
>
> On Tue, Feb 4, 2014 at 12:42 PM, Martin Gonzalez Glez <
> martin.c.glez.g...@gmail.com> wrote:
>
> > Hi everyone! My name is Martin Gonzalez, I work in the IBM Mobile
> > Foundation, and my job role it's help and contribute with this amazing
> > project that Cordova is. I really want to contribute to the success and
> > development in any way possible.
> > You may already know some folks, that I'm working with (Marcel Kinard,
> > Michael Billau, James Jong, Lisa Deluca).
> > I have good command using Javascript, Java, C/C++, HTML and another
> > languages, however, I don't have much experience with Cordova yet, but
> I'm
> > really focused on increase my knowledge and expertise.
> > If you have any questions, please feel free to contact me.
> > Thanks.
> > Martin Gonzalez.
> >
>

Re: JAVA_HOME

[Lorin Beer]

was the only impetus for using JAVA_HOME to check if java is installed?


On Mon, Dec 2, 2013 at 8:41 PM, Michal Mocny  wrote:

> Mark was kind enough to fix this for us.  We should mark the JIRA as
> resolved.  (Actually he used your suggestion Brian, check to make sure you
> can run java -version, thats it ;)
>
> commit 2f66ec60db8749bc442095560d5713b7bb718527
> Author: Mark Koudritsky 
> Date:   Wed Nov 27 16:59:20 2013 -0500
>
>
>
> On Mon, Dec 2, 2013 at 11:09 PM, Lorin Beer  >wrote:
>
> > Comment out the call to check_java, and the CLI can successfully compile,
> > and install the app to device or emulator successfully.
> >
> > So for what functionality is JAVA_HOME necessary for?
> >
> >
> >
> > On Mon, Dec 2, 2013 at 6:33 PM, Brian LeRoux  wrote:
> >
> > > I'm trying to understand why we are doing this and how it got pushed so
> > > this type of thing does not happen again.
> > >
> > > I have java. I can java -version it right now.
> > >
> > > Why are we checking for an environment variable called JAVA_HOME?
> > >
> > >
> > > On Tue, Dec 3, 2013 at 1:21 PM, Carlos Santana 
> > > wrote:
> > >
> > > > check_java() was never called properly from run() until recently
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-android/commit/5ab11edad230980379282c5a6b83eec12f7b1c5b#diff-f477d7d5a4a7b8cc0bfe70b71a81920f
> > > >
> > > > for now I worked around on Mac by
> > > > export JAVA_HOME=$(/usr/libexec/java_home)
> > > >
> > > > :-(
> > > >
> > > >
> > > > On Mon, Dec 2, 2013 at 8:59 PM, Brian LeRoux  wrote:
> > > >
> > > > > https://issues.apache.org/jira/browse/CB-5422
> > > > >
> > > > > why?!
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Carlos Santana
> > > > 
> > > >
> > >
> >
>

Re: JAVA_HOME

[Lorin Beer]

Comment out the call to check_java, and the CLI can successfully compile,
and install the app to device or emulator successfully.

So for what functionality is JAVA_HOME necessary for?



On Mon, Dec 2, 2013 at 6:33 PM, Brian LeRoux  wrote:

> I'm trying to understand why we are doing this and how it got pushed so
> this type of thing does not happen again.
>
> I have java. I can java -version it right now.
>
> Why are we checking for an environment variable called JAVA_HOME?
>
>
> On Tue, Dec 3, 2013 at 1:21 PM, Carlos Santana 
> wrote:
>
> > check_java() was never called properly from run() until recently
> >
> >
> >
> https://github.com/apache/cordova-android/commit/5ab11edad230980379282c5a6b83eec12f7b1c5b#diff-f477d7d5a4a7b8cc0bfe70b71a81920f
> >
> > for now I worked around on Mac by
> > export JAVA_HOME=$(/usr/libexec/java_home)
> >
> > :-(
> >
> >
> > On Mon, Dec 2, 2013 at 8:59 PM, Brian LeRoux  wrote:
> >
> > > https://issues.apache.org/jira/browse/CB-5422
> > >
> > > why?!
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > 
> >
>

Re: 3.3.0?

[Lorin Beer]

I'm not so pumped on cramming a new release right as the team will be
leaving for Christmas holidays.

How about a 3.2.1 release with the updated support of Android? I think a
minor version bump would be a lot more tractable given the timeframe, and I
don't know that the other platforms have enough improvement to warrant a
3.3 tag.

- Lorin


On Mon, Dec 2, 2013 at 2:49 PM, Joe Bowser  wrote:

> Hey
>
> Does anyone think we can do a 3.3.0 release sometime before Dec 13th?
> I'd like to have one more release before the end of the year that
> supports the new KitKat phones and adds the Chrome Remote Debugging.
>
> How do other people feel about this?
>
> Joe
>

Re: iOS Camera asking for Location

[Lorin Beer]

looks like we have reached consensus, but just to reiterate:

inclusion of the exif data including location was a desired feature: -1 to
ripping it out.

The current approach is to provide users the ability to turn it off: +1


On Sun, Dec 1, 2013 at 6:06 AM, James Jong  wrote:

> +1 to make it an option.
> -James Jong
>
> On Nov 29, 2013, at 3:43 PM, Andrew Grieve  wrote:
>
> > Yep, makes sense.
> >
> >
> >
> > On Fri, Nov 29, 2013 at 3:23 PM, Tommy-Carlos Williams
> > wrote:
> >
> >> IIRC, Camera used to NOT keep the location and other data, then that was
> >> raised as an issue and it was added in… and now it’s being ripped out
> again?
> >>
> >> I agree with it being optional, but ripping it out again, not so much.
> >>
> >> +1 for
> >>
> https://issues.apache.org/jira/browse/CB-4003?focusedCommentId=13694956&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13694956
> >>
> >>
> >>
> >> On 30 Nov 2013, at 6:43 am, Michal Mocny  wrote:
> >>
> >>> Ah, thats a good point (us canadians do forget!), we will make sure to
> >>> factor that into silent consensus!  (Land all the patches now, boys!)
> >>>
> >>>
> >>> On Fri, Nov 29, 2013 at 2:13 PM, Shazron  wrote:
> >>>
>  I believe Lorin is working on it being a preference, with it turned
> off
> >> by
>  default. https://issues.apache.org/jira/browse/CB-4003
> 
>  Also FYI Adobe US ppl are away for the turkey long weekend, so
> responses
>  might be late
> 
> 
>  On Fri, Nov 29, 2013 at 11:04 AM, Michal Mocny 
>  wrote:
> 
> > I agree, rip it out.  I'd love to see a plugin for editing EXIF data
>  using
> > this code as a starting point perhaps, but I can't see how what we
> have
>  now
> > is a good default.
> >
> > -Michal
> >
> >
> > On Fri, Nov 29, 2013 at 1:25 PM, Andrew Grieve  >
> > wrote:
> >
> >> On iOS, the Camera API has an undocumented feature where it injects
>  your
> >> location into a photo's exif data.
> >>
> >> Although neat, I think this isn't desired in most cases and it
> causes
> >> a
> >> location permission dialog to appear.
> >>
> >> I'd like to delete this location logic. Any objections?
> >>
> >
> 
> >>
> >>
>
>

Re: Introductory Email

[Lorin Beer]

glad to have you contributing Josh!

On Mon, Dec 2, 2013 at 8:11 AM, Josh Soref  wrote:

> Hello,
>
> As people have probably noticed, I’m one of the BlackBerry developers
> working on Cordova / cordova-blackberry as part of the WebWorks team. We
> just released our WebWorks 2.0 Beta [1] last week.
>
> Before joining BlackBerry, I worked on the Mozilla project.
>
> Additionally, I’ve been involved with the W3C including the WebApps and
> DAP Working Groups.
> - WebApps created the Widgets-Packaging W3 Recommendation around which
> config.xml is based.
> - DAP is the group who wrote a Contacts API – which was never published as
> a W3 Recommendation – which Cordova adopted.
>
> I also have experience w/ Windows, so there will be (and in fact are) pull
> requests from me to improve the state of Cordova there as well.
>
> (Yes, I know it’s kind of late for me to send an introductory email. But
> we figured it made more sense for me to start contributing and send
> something like this later.)
>
> [1]
> http://devblog.blackberry.com/2013/11/blackberry-webworks-sdk-2-0-beta-released-with-lots-of-apache-cordova-goodness/
> -
> 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.
>
>

Re: question

[Lorin Beer]

Hi Zuma,

the dev list may not be the best place to get an answer. This list handles
discussions and issues around developing Cordova itself, not developing *with
*Cordova.

That having been said, you can take a look at
UIWebViewDelegate
protocol
or  
NSURLRequest
documentation.
Both provide techniques to intercept and redirect based on the url the
WebView is trying to open.

You can look at the iOS View Controller programming
guidefor
more information on how that portion would be implemented.

Hope that helps,

- Lorin

On Mon, Dec 2, 2013 at 9:12 AM, ZUMA  wrote:

> Hello,
>
> I am trying to figure out how to load my custom view controller in my iOS
> app within the Cordova Framework.
>
> For example, I want to load a custom view controller if the url that
> cordova is trying to open contains a certain string….
>
> What method can I interact with to achieve this within the cordova
> framework?
>
> Thank you
>
>

Cordova CLI minor update

[Lorin Beer]

Michael and I released another version of the Cordova CLI this morning.

This is a minor version bump, and includes a commit to fix a blocking issue
for projects that consume the Cordova CLI as a library.

This was tested on OSX and Windows before the release, and should not
affect the Cordova CLI at all.

In the future, the list will be notified prior before even a minor release
like this.


- Lorin

Re: CLI testing

[Lorin Beer]

+1 on reverting these out. Pushing large commits that causes widespread
failing tests on one or more platforms should be reverted out. They should
not be pushed up to master in the first place.


On Wed, Nov 27, 2013 at 1:16 PM, Steven Gill  wrote:

> I think we should revert these out and put them on a branch until ready.
>
> Thoughts?
>
>
> On Wed, Nov 27, 2013 at 12:59 PM, Jesse  wrote:
>
> > okay, yeah, just switched over to OSX, and there are numerous (59)
> failures
> > here too as well.
> >
> > I have verified that these are all a result of the e2e tests folder, if
> you
> > run :
> > jasmine-node --color spec
> >
> > You will not see any of these failures.
> >
> > blame @mmocny ;)
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Wed, Nov 27, 2013 at 12:44 PM, David Kemp 
> wrote:
> >
> > > a recent set of commits landed about 1/2 hour ago has broken the CLI
> > tests
> > >
> > > 343 tests, 572 assertions, 59 failures
> > >
> > >
> > > looks like most are : Error: ENOENT, no such file or directory
> > >
> >
>

Re: [For discussion] windows8 and run/emulate commands meaning

[Lorin Beer]

+1, we want the cli commands to mean the exact same thing regardless of
platform targeted. 'Conjugating' the command based on platform breaks this
design.

Better to fail noisily with the commands that are not supported, and
document everything along the way.


On Tue, Nov 26, 2013 at 5:13 PM, Jesse  wrote:

> Yeah, when I explored this a while back, I thought the following made the
> most sense:
>
> run --emulator => outputs 'emulator is not supported' until we can get it
> to work
> run --target => outputs 'target mode is not supported' until we can get it
> to work
> run --device => runs on the current device
>
> I think it is less confusing to just have the --emulator/emulate command
> fail noisily.
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Nov 26, 2013 at 4:08 PM, Parashuram Narasimhan (MS OPEN TECH) <
> panar...@microsoft.com> wrote:
>
> > I think using Cordova run and emulate to do the same thing for now makes
> > sense. Instead of just leaving it out as unimplemented, we could deploy
> to
> > local machine in both cases. I am working with the Windows team to see if
> > we could run the app on an emulator, and if we have an answer for that,
> we
> > would update it.
> >
> > -Original Message-
> > From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com]
> > Sent: Wednesday, November 20, 2013 7:59 PM
> > To: dev@cordova.apache.org
> > Subject: [For discussion] windows8 and run/emulate commands meaning
> >
> > Hi,
> >
> > Cordova cli provides the following three options to execute your app from
> > the shell:
> >
> > * run --emulator (or emulate) - to run the app on emulator
> >
> > * run --device - app will be executed on the connected device
> >
> > * run --target - same as above, but you specify particular device
> >
> > Right now the only known method to programmatically start Windows Store
> > app is to start it locally right on your system. Windows8 platform is
> > special since you technically build your app right on the target
> > platform/device. Due to this I propose to treat both run/emulate commands
> > for Windows8 platform as running app locally.
> >
> > Motivation:
> >
> > 1.   People actively use both run and emulate commands so it will be
> > great to somehow support them both.
> >
> > 2.   Right now we only know how to start app locally. Not sure we
> will
> > be able to implement other options in the near future. If we find the way
> > to support additional options we will change run/emulate meaning later.
> >
> > Thoughts?
> >
> > Additional details
> > When you are working with Windows Store app in Visual Studio there are
> the
> > following three options to test your app
> >
> > * Local Machine - app will be run right on your local system
> >
> > o   easy to automate from command prompt
> >
> > o
> >
> https://github.com/sgrebnov/cordova-windows/commit/7577a589766e14c2e2674ffb5a8081a308a743be
> >
> > * Emulator - starts Windows RT emulator
> >
> > o   at present time I don't have solution to do the same from command
> > line, continue research..
> >
> > * Remote Machine - app will be run on remote machine (you should
> > specify target machine ip address + install special software on remote
> > machine - VS Remote Debugging Tools)
> >
> > o   looks like we won't be able to support this option in the near future
> > since it is very complex
> >
> > Thx!
> > Sergey
> >
>

Re: [FxOS] Special needs for contact plugin

[Lorin Beer]

traditionally, we have had a per platform quirks section in the relevant
api's documentation.

Search for quirks in the contacts
api
and
you should find sections for Android, BlackBerry, iOS and WP 7 and 8.

Just add a FireFox OS section, and document quirks there.




On Wed, Nov 27, 2013 at 9:11 AM, Piotr Zalewa  wrote:

> Hi,
>
> I've almost finished the Contacts proxy for Firefox OS. [1]
>
> Access to contacts API in FxOS requires webapp to be "privileged" and
> special permissions needs to be set in app's manifest.
> The privileged app enforces Content Security Policy [2] which doesn't
> allow for inline javascript.
>
> Because of both above special documentation is needed. Where should I put
> it?
>
> Thanks
> Piotr
>
>
> [1] https://github.com/zalun/cordova-plugin-contacts
> [2] https://developer.mozilla.org/en-US/Apps/CSP
>

Re: Intro email

[Lorin Beer]

Hi Kyle, welcome to the list!


On Wed, Nov 27, 2013 at 9:01 AM, James Jong  wrote:

> Welcome Kyle!
> -James Jong
>
> On Nov 27, 2013, at 10:41 AM, Kyle Nitzsche 
> wrote:
>
> > Hi,
> >
> > I am Kyle Nitzsche, and I work for Canonical on Ubuntu.
> >
> > I will be providing the docs for the Ubuntu platform support recently
> submitted.
> >
> > Cheers,
> > Kyle
>
>

Re: amazon-fireos pull requests

[Lorin Beer]

I've been looking at the fireos cli pull request. It passes all manual and
auto tests, but no fireos target is available. Once I determine the
problem, I'll push it up.


On Mon, Nov 18, 2013 at 3:42 PM, Steven Gill  wrote:

> In comparison, I just tried merging ubuntu code into cordova-ubuntu. No
> problems.
> https://git-wip-us.apache.org/repos/asf?p=cordova-ubuntu.git;a=summary
>
>
> On Mon, Nov 18, 2013 at 3:35 PM, Steven Gill 
> wrote:
>
> > Hey Guys,
> >
> > I have spent a little bit too much time trying to get this resolved.
> >
> > I was getting the following error when trying to copy over
> > cordova-amazon-fireos into apache.
> >
> http://stackoverflow.com/questions/15598465/should-i-worry-about-git-fsck-warning-contains-zero-padded-file-modes
> >
> > I tried the fix is suggests (remaking the history tree) and pushing it
> up.
> > I still keep running into issues when it comes to pushing this onto
> apache.
> > I am getting the following error now.
> >
> > remote: Error: list index out of range
> > To https://git-wip-us.apache.org/repos/asf/cordova-amazon-fireos.git
> >   ! [remote rejected] master -> master (pre-receive hook declined)
> > error: failed to push some refs to '
> > https://git-wip-us.apache.org/repos/asf/cordova-amazon-fireos.git'
> >
> > I am not sure how to solve this issue. I've been googling around for a
> > bit. Maybe I am missing something obvious. Force pushing isn't working
> > (Apache has that blocked I believe). An easy solution is to nuke the
> > history. I am seriously considering doing this. I have tried multiple
> > different ways to debug this and haven't had any success so far.
> >
> > Thoughts?
> >
> >
> >
> >
> > On Mon, Nov 18, 2013 at 10:22 AM, Naik, Archana 
> wrote:
> >
> >> Hi, Carlos
> >>
> >> Thank you for your suggestions. I will look at those repos. FWIW, we are
> >> using "modified" mobile-spec to test amazon-fireos port and plug-ins. We
> >> run both automated and manual tests.
> >>
> >> Archana
> >>
> >> On 11/18/13 8:26 AM, "Carlos Santana"  wrote:
> >>
> >> >Naik,
> >> >  I'm sorry for the stupid typo: I meant "branch 'cdvtest' per plugin"
> >> >
> >> >
> >> >On Mon, Nov 18, 2013 at 11:25 AM, Carlos Santana
> >> >wrote:
> >> >
> >> >> Naik Thanks for all this contributions and bringing a new platform to
> >> >>the
> >> >> Cordova Family !
> >> >>
> >> >> I will recommend to take a look at the following if you have not
> >> already
> >> >> done so.
> >> >>
> >> >> Mobile Spec: Our current generation test framework App with automated
> >> >>and
> >> >> manual tests.
> >> >> https://github.com/apache/cordova-mobile-spec
> >> >>
> >> >>
> >> >> Next Generation Test Framework: (branch cdv-test)
> >> >> https://github.com/apache/cordova-labs/tree/cdvtest
> >> >>
> >> >>
> >> >> Next Generation Test Plugin Structure: (branch cdv-test pre plugin)
> >> >> Look in each individual plugin repo for a branch "cdv-test" like
> >> >> https://github.com/apache/cordova-plugin-contacts/tree/cdvtest
> >> >> Not all plugins are ported yet, (help is always appreciated :-) )
> >> >>
> >> >> --Carlos
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Nov 15, 2013 at 5:01 PM, Joe Bowser 
> wrote:
> >> >>
> >> >>> Excellent! Thanks for sending the pull requests.
> >> >>> On Nov 15, 2013 1:34 PM, "Naik, Archana"  wrote:
> >> >>>
> >> >>> > Hello, Devs
> >> >>> >
> >> >>> > As you guys know, I am working on cordova amazon-fireos platform
> >> >>>port. I
> >> >>> > have made changes in CLI, core plug-ins and plugman repos to add
> >> >>> > amazon-fireos platform support.
> >> >>> > We would like to support cordova 3.0 and above. Most repos have
> >> >>>master,
> >> >>> > 3.0.x and 3.1.x branches. Below is the list of repos and pull
> >> request
> >> >>> URLS.
> >> >>> >
> >> >>> > Cordova-amazon-fireos
> >> >>> >
> >> >>> > Github url : https://github.com/archananaik/cordova-amazon-fireos
> >> >>> > Cordova-amazon-fireos repository has master, Cordova-3.1.x and
> 3.0.x
> >> >>> > branches that I would like to be imported to apache
> >> >>> cordova-amazon-fireos
> >> >>> > repo.
> >> >>> >
> >> >>> > Pull requests
> >> >>> >
> >> >>> > CLI
> >> >>> >
> >> >>> > Master - https://github.com/apache/cordova-cli/pull/94
> >> >>> > Cordova-3.1.x - https://github.com/apache/cordova-cli/pull/89
> >> >>> > 3.0.x - https://github.com/apache/cordova-cli/pull/90
> >> >>> >
> >> >>> > Plugman
> >> >>> >
> >> >>> > master - https://github.com/apache/cordova-plugman/pull/34
> >> >>> > Cordova-3.1.x - https://github.com/apache/cordova-plugman/pull/35
> >> >>> >
> >> >>> > cordova-plugin-battery-status
> >> >>> >
> >> >>> > Dev -
> >> https://github.com/apache/cordova-plugin-battery-status/pull/6
> >> >>> > Master -
> >> >>>https://github.com/apache/cordova-plugin-battery-status/pull/5
> >> >>> >
> >> >>> > cordova-plugin-camera
> >> >>> >
> >> >>> > Dev - https://github.com/apache/cordova-plugin-camera/pull/4
> >> >>> > Master - https://github.com/apache/cordova-plugin-camera/pull/5

Re: [proposal] Deprecate WP7 as a target platform

[Lorin Beer]

+1


On Mon, Nov 18, 2013 at 12:43 PM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> +1
>
> Some interesting usage statistics:
> http://blog.adduplex.com/2013/09/adduplex-windows-phone-statistics.html
>
> -Sergey
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Tuesday, November 19, 2013 12:42 AM
> To: dev@cordova.apache.org
> Subject: Re: [proposal] Deprecate WP7 as a target platform
>
> +1
>
>
> On Mon, Nov 18, 2013 at 12:22 PM, Jesse  wrote:
>
> > I would like to add a deprecation notice to WP7, so we can move
> > forward with one platform for Windows Phone.
> > Windows Phone 8 has been available for over a year, and mostly taken
> > over for WP7.
> > WP7 devices are currently still available, mostly as an inexpensive
> > way to get a windows phone.
> > The WP8 Lumia 520 has made considerable impact as a low cost WP8
> > device, and Nokia is expected to stop selling WP7 devices shortly.
> > Our ~6 month deprecation windows would put us at May of 2014 for
> > officially dropping support.
> >
> > The upgrade path for converting your WP7 Cordova app to WP8 Cordova is
> > trivial, with the exception that it requires updated tools.  WP8 app
> > dev requires Windows 8 and Visual Studio 2012. ( WP7 required Windows
> > 7 +
> > VS-2010 + Zune )
> >
> >
> > @purplecabbage
> > risingj.com
> >
>

Re: cordova-js commits on master but not on 3.2.x branch

[Lorin Beer]

well, I had an updated version of plugman and I checked at multiple tags.
I'll do some more investigation.


On Fri, Nov 8, 2013 at 3:11 PM, Bryan Higgins wrote:

> Thanks Lorin.
>
> I'll take a look this weekend. Plugin installation has been working
> correctly without the blank permissions element for a while now. I did not
> experience any issues with plugins when I tagged earlier this week.
>
> On Friday, November 8, 2013, Lorin Beer  wrote:
> > BB has been retagged, fixed an issue which blocked plugin installation.
> > Core is ready, but there are major issues with multiple plugins.
> >
> >
> > On Fri, Nov 8, 2013 at 2:10 PM, Lorin Beer 
> wrote:
> >
> >> currently testing BB, should be retagged in about 10 minutes
> >>
> >>
> >> On Thu, Nov 7, 2013 at 8:59 PM, purplecabbage  >wrote:
> >>
> >>> And the js commits for blackberry did not change the js for other
> >>> platforms! Win win.
> >>>
> >>> Sent from my iPhone
> >>>
> >>> > On Nov 7, 2013, at 6:56 PM, Carlos Santana 
> >>> wrote:
> >>> >
> >>> > Thank you Steve !
> >>> >
> >>> >
> >>> >> On Thu, Nov 7, 2013 at 8:06 PM, Steven Gill  >
> >>> wrote:
> >>> >>
> >>> >> Sweet. None of these require re-tagging cordova-js.
> >>> >>
> >>> >>
> >>> >>> On Thu, Nov 7, 2013 at 3:50 PM, Josh Soref 
> >>> wrote:
> >>> >>>
> >>> >>> Carlos wrote:
> >>> >>>> Should the following commits should be included for 3.2 specially
> >>> >>> BB10 changes?
> >>> >>>
> >>> >>> On the subject of changes designed for 3.2, this set (for CCB-5258)
> is
> >>> >> the
> >>> >>> only thing I have that I really want to get it in:
> >>> >>> https://github.com/apache/cordova-cli/pull/70
> >>> >>> https://github.com/apache/cordova-coho/pull/7
> >>> >>> https://github.com/apache/cordova-plugman/pull/32
> >>> >>> https://github.com/apache/cordova-android/pull/82
> >>> >>> https://github.com/apache/cordova-ios/pull/82
> >>> >>>
> >>> >>> The BlackBerry portion has landed.
> >>> >>>
> -
> >>> >>> 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.
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Carlos Santana
> >>> > 
> >>>
> >>
> >>
> >
>

Re: cordova-js commits on master but not on 3.2.x branch

[Lorin Beer]

BB has been retagged, fixed an issue which blocked plugin installation.
Core is ready, but there are major issues with multiple plugins.


On Fri, Nov 8, 2013 at 2:10 PM, Lorin Beer  wrote:

> currently testing BB, should be retagged in about 10 minutes
>
>
> On Thu, Nov 7, 2013 at 8:59 PM, purplecabbage wrote:
>
>> And the js commits for blackberry did not change the js for other
>> platforms! Win win.
>>
>> Sent from my iPhone
>>
>> > On Nov 7, 2013, at 6:56 PM, Carlos Santana 
>> wrote:
>> >
>> > Thank you Steve !
>> >
>> >
>> >> On Thu, Nov 7, 2013 at 8:06 PM, Steven Gill 
>> wrote:
>> >>
>> >> Sweet. None of these require re-tagging cordova-js.
>> >>
>> >>
>> >>> On Thu, Nov 7, 2013 at 3:50 PM, Josh Soref 
>> wrote:
>> >>>
>> >>> Carlos wrote:
>> >>>> Should the following commits should be included for 3.2 specially
>> >>> BB10 changes?
>> >>>
>> >>> On the subject of changes designed for 3.2, this set (for CCB-5258) is
>> >> the
>> >>> only thing I have that I really want to get it in:
>> >>> https://github.com/apache/cordova-cli/pull/70
>> >>> https://github.com/apache/cordova-coho/pull/7
>> >>> https://github.com/apache/cordova-plugman/pull/32
>> >>> https://github.com/apache/cordova-android/pull/82
>> >>> https://github.com/apache/cordova-ios/pull/82
>> >>>
>> >>> The BlackBerry portion has landed.
>> >>> -
>> >>> 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.
>> >
>> >
>> >
>> > --
>> > Carlos Santana
>> > 
>>
>
>

Re: cordova-js commits on master but not on 3.2.x branch

[Lorin Beer]

currently testing BB, should be retagged in about 10 minutes

On Thu, Nov 7, 2013 at 8:59 PM, purplecabbage wrote:

> And the js commits for blackberry did not change the js for other
> platforms! Win win.
>
> Sent from my iPhone
>
> > On Nov 7, 2013, at 6:56 PM, Carlos Santana  wrote:
> >
> > Thank you Steve !
> >
> >
> >> On Thu, Nov 7, 2013 at 8:06 PM, Steven Gill 
> wrote:
> >>
> >> Sweet. None of these require re-tagging cordova-js.
> >>
> >>
> >>> On Thu, Nov 7, 2013 at 3:50 PM, Josh Soref 
> wrote:
> >>>
> >>> Carlos wrote:
>  Should the following commits should be included for 3.2 specially
> >>> BB10 changes?
> >>>
> >>> On the subject of changes designed for 3.2, this set (for CCB-5258) is
> >> the
> >>> only thing I have that I really want to get it in:
> >>> https://github.com/apache/cordova-cli/pull/70
> >>> https://github.com/apache/cordova-coho/pull/7
> >>> https://github.com/apache/cordova-plugman/pull/32
> >>> https://github.com/apache/cordova-android/pull/82
> >>> https://github.com/apache/cordova-ios/pull/82
> >>>
> >>> The BlackBerry portion has landed.
> >>> -
> >>> 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.
> >
> >
> >
> > --
> > Carlos Santana
> > 
>

Re: Refactoring the CLI tests

[Lorin Beer]

>What we're aiming for here is that we mock as little as is practical,

I think that kind of defeats the idea of unit tests in the first place, I
like the clean delineation between unit tests and integration tests, and it
sounds like both need to be improved. Mocking things at the boundary of the
CLI is in line with this.

>We'll do it first, and then solve the speed problems later if any arise.

agreed, and we can mitigate potential problems by keeping unit tests small
and within the boundaries of the CLI.

>My main frustration with the current state of the tests is how fragile some
of them are with respect to even minor changes in the CLI. As I see it,
this is closely related to mocking the file system calls.

Yeah, mocking file system calls is a little goofy, especially considering
the scope of the CLI as a project. We can reasonably expect  a user to have
an HD, no?

My philosophy on testing is not to waste time optimizing tests, it's to
keep the tests small and lightweight. Each test deals with the smallest
unit of code or functionality possible. That's what makes them fast.
Integration tests deal with functionality that encompasses
inter-process/inter-project/network communication, and where latency is
expected.




On Thu, Nov 7, 2013 at 4:32 PM, Mark Koudritsky  wrote:

> My main frustration with the current state of the tests is how fragile some
> of them are with respect to even minor changes in the CLI. As I see it,
> this is closely related to mocking the file system calls. CLI is all about
> massaging the files around, most of the state we care about lives on the
> file system. So once we mock the fs calls and can't check for existence and
> contents of files, we don't have much to check for in the tests, so we
> start checking implementation details like specific function calls and then
> it gets fragile. As far as I understand, the kind of relationship that CLI
> has with the file system is not so common with other Node.js based projects
> and the distinction between unit and integration tests is somewhat blurred
> here.
>
> Anyway, as Braden said, we'll see what parts of the end-to-end tests will
> be slow and work on speeding some of them up and mocking others away. I've
> fallen prey to premature optimization traps way too many times by now :)
>
> - Mark
>
>
> On Thu, Nov 7, 2013 at 3:06 PM, Braden Shepherdson  >wrote:
>
> > What we're aiming for here is that we mock as little as is practical, and
> > ideally only mock things at the boundaries of CLI: calls to the platform
> > scripts, some calls to Plugman (generally we want to let these end-to-end
> > tests call the real Plugman, but there are exceptions).
> >
> > We'll do it first, and then solve the speed problems later if any arise.
> > There are some options here, like I mentioned above: Use a fake fs
> > implementation[1] or a ramdisk with (much!) better performance than the
> > real disk. And just make CLI faster in general.
> >
> > Braden
> >
> > [1] https://github.com/eldargab/node-fake-fs
> >
> >
> > On Thu, Nov 7, 2013 at 2:57 PM, Anis KADRI  wrote:
> >
> > > The reason why every FS call is mocked is speed but speed is
> > > subjective in my opinion. Given the features of CLI, my opinion is
> > > that anything < 1 minute is acceptable. When I run tests, I am not
> > > actively watching them execute.
> > > I think the only calls that should be mocked are network calls because
> > > you should be able to run tests offline.
> > > I think we should convert (trash?) existing tests back to what they
> > > were instead of adding more end-to-end tests. We should also pay more
> > > attention de Windows.
> > >
> > > On Thu, Nov 7, 2013 at 10:31 AM, Braden Shepherdson <
> bra...@chromium.org
> > >
> > > wrote:
> > > > Alright, Mark and I have discussed this further, and we will be
> > beginning
> > > > the effort with some end-to-end tests that will supplement the
> existing
> > > > tests.
> > > >
> > > > To some extent this is duplicating things that go on in the CI, since
> > it
> > > > checks out various plugins using the tools. But we think it's still a
> > > > worthwhile effort since it will make it much easier to catch any
> > problems
> > > > at commit time.
> > > >
> > > > The main pain point in the existing tests that we'll want to fix is
> > their
> > > > fragility. The worst offenders here are the platform parsers,
> > especially
> > > > wp7+8. So Steve, if you're looking for ways to help, I'd suggest
> > looking
> > > at
> > > > those (wp in particular, but all of them). These are some of the
> worst,
> > > > most vacuous tests we have. They're not providing sample inputs and
> > > > checking the outputs, they are checking that the right functions get
> > > > called. I propose that they should be operating on a real,
> checked-in,
> > > > example project, in the spec/fixtures directory. The tests should run
> > the
> > > > parsers, and make sure all the files are in the right places and have
> > the
> > > > right contents.
>

Re: Refactoring the CLI tests

[Lorin Beer]

This reiterates some of the conclusions Braden and Mark have already
reached, but generally testing should be split into two categories: unit
tests and integration tests.

There's debate about whether things like the file system should be mocked
or not, but I think it's wrong to call our current tests bad, they are just
incomplete.

1. Unit tests should run fast, each test should run in milliseconds.
2. integration tests include end-to-end communication, and speed is not
important

+1 for expanding current unit tests for improved coverage

I suggest including a separate suite of tests (re: run independently of
unit tests). The idea is that the unit tests can be run as part of
development, integration tests run once before you push a change.


On Thu, Nov 7, 2013 at 11:57 AM, Anis KADRI  wrote:

> The reason why every FS call is mocked is speed but speed is
> subjective in my opinion. Given the features of CLI, my opinion is
> that anything < 1 minute is acceptable. When I run tests, I am not
> actively watching them execute.
> I think the only calls that should be mocked are network calls because
> you should be able to run tests offline.
> I think we should convert (trash?) existing tests back to what they
> were instead of adding more end-to-end tests. We should also pay more
> attention de Windows.
>
> On Thu, Nov 7, 2013 at 10:31 AM, Braden Shepherdson 
> wrote:
> > Alright, Mark and I have discussed this further, and we will be beginning
> > the effort with some end-to-end tests that will supplement the existing
> > tests.
> >
> > To some extent this is duplicating things that go on in the CI, since it
> > checks out various plugins using the tools. But we think it's still a
> > worthwhile effort since it will make it much easier to catch any problems
> > at commit time.
> >
> > The main pain point in the existing tests that we'll want to fix is their
> > fragility. The worst offenders here are the platform parsers, especially
> > wp7+8. So Steve, if you're looking for ways to help, I'd suggest looking
> at
> > those (wp in particular, but all of them). These are some of the worst,
> > most vacuous tests we have. They're not providing sample inputs and
> > checking the outputs, they are checking that the right functions get
> > called. I propose that they should be operating on a real, checked-in,
> > example project, in the spec/fixtures directory. The tests should run the
> > parsers, and make sure all the files are in the right places and have the
> > right contents.
> >
> > Braden
> >
> >
> > On Thu, Nov 7, 2013 at 1:02 PM, Steve Gill 
> wrote:
> >
> >> I don't think we should scrap the current tests. I am totally in favor
> of
> >> having new end to end tests. We need to catch regressions better.
> >>
> >> Braden, let me know how I can help.
> >>
> >>
> >>
> >> > On Nov 7, 2013, at 9:02 AM, Michal Mocny  wrote:
> >> >
> >> > Discussing locally with Braden.. these tests seem to be testing
> internal
> >> > details instead of expected functionality.  Its quite common for valid
> >> > patches to break the tests and invalid patches to leave the tests
> >> passing.
> >> > There have been several occurrences recently where things landed even
> >> > though "cordova create" or "plugin add" were hosed, which seems fairly
> >> > fundamental to keep working ;)
> >> >
> >> >
> >> >> On Thu, Nov 7, 2013 at 11:57 AM, Michal Mocny 
> >> wrote:
> >> >>
> >> >> +1 to testing end-to-end, but I thought thats what BuildBot/Medic
> does?
> >> >> Likely we want to ship those end-to-end test scripts so users can
> test
> >> >> changes locally, but I think the tests are are inside CLI now are
> meant
> >> to
> >> >> be unit tests, which yes, have very limited usefulness in isolation,
> but
> >> >> perhaps shouldn't be entirely replaced?  If they really are useless
> (not
> >> >> sure) then they should be fixed/removed.
> >> >>
> >> >>
> >> >> On Thu, Nov 7, 2013 at 11:40 AM, Braden Shepherdson <
> >> bra...@chromium.org>wrote:
> >> >>
> >> >>> The CLI tests are bad. I propose making them better.
> >> >>>
> >> >>> The tests are bad for two reasons:
> >> >>> 1. They're fragile because the tests depend on exactly the right
> >> functions
> >> >>> being called, sometimes in the right order.
> >> >>> 2. They don't test what we really want, which is that projects get
> >> created
> >> >>> and all the files are in the right places.
> >> >>>
> >> >>> I propose letting the tests actually run filesystem and related
> calls,
> >> >>> instead of always mocking them out. In the simplest form, that means
> >> >>> running them on the real filesystem. If that's too slow, we can
> >> >>> investigate
> >> >>> other alternatives, like using a ramdisk, or using that emulated fs
> >> that
> >> >>> runs everything in RAM inside Node.
> >> >>>
> >> >>> Mark and I are planning to work on this, starting with the CLI
> tests.
> >> The
> >> >>> Plugman tests are better in this regard, but could probably stand
> to be
> >> >>> really called as wel

Re: Medic/CI

[Lorin Beer]

great work, thanks David!


On Thu, Nov 7, 2013 at 11:04 AM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> Great news David, thank you!
>
> -Sergey
> -Original Message-
> From: drk...@google.com [mailto:drk...@google.com] On Behalf Of David Kemp
> Sent: Thursday, November 7, 2013 10:55 PM
> To: dev@cordova.apache.org
> Subject: Medic/CI
>
> After a little turmoil, the medic repo is now up to date with the Windows
> support added, and still working on mac/ios/android.
>
> Thanks for the additions Sergey!
>
> ** and everything except CLI is green **
>

Re: Review Request 15286: Cordova 2.9.1 release blog post

[Lorin Beer]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15286/#review28336
---


I don't feel this is up to the standard of Cordova blog posts.

On line 11, the '!?' should be '?!' as it is a question which is emphasized, 
not a questionable emphasization.

On line 15 "but highly" should be "but we highly"

that is all.

- Lorin Beer


On Nov. 6, 2013, 11:12 p.m., Steven Gill wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15286/
> ---
> 
> (Updated Nov. 6, 2013, 11:12 p.m.)
> 
> 
> Review request for cordova.
> 
> 
> Repository: cordova-site
> 
> 
> Description
> ---
> 
> Blog post for 2.9.1 release
> 
> 
> Diffs
> -
> 
>   /cordova/site/www/_posts/2013-11-06-cordova-291.md PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15286/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Steven Gill
> 
>

Re: CommandProxy and misbehaving plugins

[Lorin Beer]

ah, I misunderstood Gord's post.

Yes, this would be a welcome solution to this. +1.


On Tue, Oct 29, 2013 at 10:47 AM, Bryan Higgins wrote:

> Lorin - with Gord's generic command proxy vibrate would still execute
> within the main content webview
>
> I'm in favour of using this.
>
>
> On Tue, Oct 29, 2013 at 1:35 PM, Lorin Beer  >wrote:
>
> > Hey Gord,
> >
> > handling Vibrate behind the exec layer was attempted, but unfortunately
> > exec calls occur in a separate webview, and the call to vibrate isn't
> > executed.
> > We've talked about a few ways around this, and a jira ticket would be
> > appreciated.
> >
> > - Lorin
> >
> >
> > On Tue, Oct 29, 2013 at 12:20 AM, Jesse  wrote:
> >
> > > Welcome back!
> > >
> > > Yeah, I chose to make windows8 run the exact same js as the other
> > devices,
> > > and strove for a consistent exec signature. This was the initial goal
> of
> > > having a cordova-js in the first place.
> > > When I saw firefoxos requiring the same kind of functionality, I
> > suggested
> > > they use the same classes, but we were in a hurry, so it was not
> > refactored
> > > into the single module, although this was the plan.
> > >
> > > Incidentally, in 2.9.0 this WAS in it's own module, but it was
> refactored
> > > out so it only existed in the windows8 platform.[1]
> > >
> > > [1]
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob;f=lib/common/commandProxy.js;h=e6400038a918174ca02ea889cbe14b82750a8a2b;hb=83dc4bd9010447ea9b93889481516c64a9a46cde
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Mon, Oct 28, 2013 at 9:09 PM, Gord Tanner 
> wrote:
> > >
> > > > Hey everyone,
> > > >
> > > > Long time no commit but I was working on getting cordova 3.X support
> > > > working in ripple (really really close and about to release it) but I
> > saw
> > > > some weird stuff in some of the plugins.
> > > >
> > > > In the vibration plugin the base javascript calls into the cordova
> exec
> > > > module [1] and does all the work in the native layer, which is
> perfect.
> > > >
> > > > BlackBerry 10 overrides the base javascript with their own
> > implementation
> > > > that just delegates this to navigator.vibrate [2].  This isn't a
> unique
> > > > problem as firefox does the same thing but handles it behind the exec
> > > layer
> > > > [3].
> > > >
> > > > It would be nice if we could keep each platform as close to being the
> > > same
> > > > as possible and diverge behind the exec layer (like firefox does).
> > > >
> > > > I saw that windows8 and firefox both have a commandProxy that they
> use
> > to
> > > > add in services and actions for the "native" layer.  I moved this to
> a
> > > > common plugin [4] (since it was duplicated anyway).
> > > >
> > > > Now that this is a common plugin we can use it to override and add in
> > > > "native" modules so that BlackBerry and other platforms don't need to
> > > > diverge at the javascript API layer making it harder to emulate.
> > > >
> > > >
> > > > [1] -
> > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-plugin-vibration/blob/master/www/vibration.js
> > > > [2] -
> > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-plugin-vibration/blob/master/www/blackberry10/vibrate.js
> > > > [3] -
> > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-plugin-vibration/blob/master/src/firefoxos/VibrationProxy.js
> > > > [4] -
> > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commitdiff;h=c6817556d90cc4e500c4f480b6e106b1b52d3002
> > > >
> > >
> >
>

Re: CommandProxy and misbehaving plugins

[Lorin Beer]

Hey Gord,

handling Vibrate behind the exec layer was attempted, but unfortunately
exec calls occur in a separate webview, and the call to vibrate isn't
executed.
We've talked about a few ways around this, and a jira ticket would be
appreciated.

- Lorin


On Tue, Oct 29, 2013 at 12:20 AM, Jesse  wrote:

> Welcome back!
>
> Yeah, I chose to make windows8 run the exact same js as the other devices,
> and strove for a consistent exec signature. This was the initial goal of
> having a cordova-js in the first place.
> When I saw firefoxos requiring the same kind of functionality, I suggested
> they use the same classes, but we were in a hurry, so it was not refactored
> into the single module, although this was the plan.
>
> Incidentally, in 2.9.0 this WAS in it's own module, but it was refactored
> out so it only existed in the windows8 platform.[1]
>
> [1]
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob;f=lib/common/commandProxy.js;h=e6400038a918174ca02ea889cbe14b82750a8a2b;hb=83dc4bd9010447ea9b93889481516c64a9a46cde
>
>
> @purplecabbage
> risingj.com
>
>
> On Mon, Oct 28, 2013 at 9:09 PM, Gord Tanner  wrote:
>
> > Hey everyone,
> >
> > Long time no commit but I was working on getting cordova 3.X support
> > working in ripple (really really close and about to release it) but I saw
> > some weird stuff in some of the plugins.
> >
> > In the vibration plugin the base javascript calls into the cordova exec
> > module [1] and does all the work in the native layer, which is perfect.
> >
> > BlackBerry 10 overrides the base javascript with their own implementation
> > that just delegates this to navigator.vibrate [2].  This isn't a unique
> > problem as firefox does the same thing but handles it behind the exec
> layer
> > [3].
> >
> > It would be nice if we could keep each platform as close to being the
> same
> > as possible and diverge behind the exec layer (like firefox does).
> >
> > I saw that windows8 and firefox both have a commandProxy that they use to
> > add in services and actions for the "native" layer.  I moved this to a
> > common plugin [4] (since it was duplicated anyway).
> >
> > Now that this is a common plugin we can use it to override and add in
> > "native" modules so that BlackBerry and other platforms don't need to
> > diverge at the javascript API layer making it harder to emulate.
> >
> >
> > [1] -
> >
> >
> https://github.com/apache/cordova-plugin-vibration/blob/master/www/vibration.js
> > [2] -
> >
> >
> https://github.com/apache/cordova-plugin-vibration/blob/master/www/blackberry10/vibrate.js
> > [3] -
> >
> >
> https://github.com/apache/cordova-plugin-vibration/blob/master/src/firefoxos/VibrationProxy.js
> > [4] -
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commitdiff;h=c6817556d90cc4e500c4f480b6e106b1b52d3002
> >
>

Re: Medic tests results consolidation

[Lorin Beer]

I don't believe Iris couch will work. When I checked Iris out, they had
strict limits on what couch settings you could modify, notably accepting
requests from an external host.




On Fri, Oct 25, 2013 at 2:29 PM, Steven Gill  wrote:

> Iris couch donated a couchdb instance for plugins.cordova.io. Maybe we can
> use that same instance for this purpose.
>
>
> On Fri, Oct 25, 2013 at 2:00 PM, David Kemp  wrote:
>
> > There was an apache request out as well for a machine to run couch and
> > other things on.
> > It does not seem to be moving much.
> >
> > Currently we are just storing it locally and waiting to share...
> >
> >
> > On Fri, Oct 25, 2013 at 4:40 PM, Sergey Grebnov (Akvelon) <
> > v-seg...@microsoft.com> wrote:
> >
> > > Thank you for the info Lorin! Looking forward...
> > >
> > > -Sergey
> > > -Original Message-
> > > From: Lorin Beer [mailto:lorin.beer@gmail.com]
> > > Sent: Saturday, October 26, 2013 12:37 AM
> > > To: dev
> > > Subject: Re: Medic tests results consolidation
> > >
> > > Currently, we are setting up Adobe's Device Wall, as it was dismantled
> > and
> > > shipped down to SF from the Vancouver office. After we have working
> setup
> > > in SF, plans are to address federation of the CI systems each
> > organization
> > > has setup, and aggregate the results in a single place.
> > >
> > > This should be happening over the next two weeks.
> > >
> > > - Lorin
> > >
> > >
> > > On Fri, Oct 25, 2013 at 12:40 PM, Sergey Grebnov (Akvelon) <
> > > v-seg...@microsoft.com> wrote:
> > >
> > > > Hi,
> > > > There were plans to set up a dedicated vm to consolidate test results
> > > > from different platforms. Could someone let me know where we are? Is
> > > > there couchdb endpoint available so that I can join with my test
> > > > results and also compare to other platforms?
> > > >
> > > > Thx!
> > > > Sergey
> > > >
> > >
> >
>

Re: Medic tests results consolidation

[Lorin Beer]

Currently, we are setting up Adobe's Device Wall, as it was dismantled and
shipped down to SF from the Vancouver office. After we have working setup
in SF, plans are to address federation of the CI systems each organization
has setup, and aggregate the results in a single place.

This should be happening over the next two weeks.

- Lorin


On Fri, Oct 25, 2013 at 12:40 PM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> Hi,
> There were plans to set up a dedicated vm to consolidate test results from
> different platforms. Could someone let me know where we are? Is there
> couchdb endpoint available so that I can join with my test results and also
> compare to other platforms?
>
> Thx!
> Sergey
>

Re: Should we add platform info in commit message?

[Lorin Beer]

seems like a small change which would greatly increase the readability of
plugin history, and enable us to quickly generate platform specific
changelogs.

+1


On Thu, Oct 17, 2013 at 7:41 PM, lmnbeyond  wrote:

> Hi guys,
>
> Since plugin-related code are all grouped into its own repo, should we
> add platform info in commit messages? I think it would be more clear when
> we view the commit history.
>
> e.g.,
>
> [CB-1234][iOS] Fix…
> [CB-5678][all] Fix…
> [Android]…
> [js]…
>
> What do you think, guys?
>
>
> Best Regards!
>
>
>
>

Re: Medic / Buildbot / cordova-medic

[Lorin Beer]

great to see this hit Apache, thanks David!


On Wed, Oct 16, 2013 at 7:11 AM, David Kemp  wrote:

> I have pushed the current state of the buildbot CI to the cordova-medic
> repo.
>
> The history generally makes sense and provides flow from the medic state in
> April to the current state.
>
> Those of you using the Buildbot/medic version - if you want to use this
> repo you would need to either update your repos.json or grab the new one
> from cordova-medic.
>
> David Kemp
>

Re: Medic status and plans

[Lorin Beer]

and I do not believe there is any common history between the apache medic
repo and David's bb-test repo


On Thu, Oct 10, 2013 at 3:07 PM, Anis KADRI  wrote:

> You can't force push to apache :-/
>
> On Thu, Oct 10, 2013 at 1:40 PM, Brian LeRoux  wrote:
> > Kind of a chicken/egg problem. Will this cleanly merge or should we just
> > force push it in?
> >
> >
> > On Thu, Oct 10, 2013 at 7:42 AM, David Kemp  wrote:
> >
> >> I'm happy to put the bb-test code into the official repo.
> >> I was hoping to do that soon but I do not think I am an official
> committer
> >> yet.
> >>
> >> As for USB hubs, the 2.1A one that I picked up has recently stopped
> working
> >> on the 2.1A port.
> >> I need to get it returned and replaced, but probably cannot recommend it
> >> right now since the first one stopped working right after only about 3
> >> weeks. When it was working it was awesome.
> >>
> >> Keeping iPads and tablets charged is definitely the hard part.
> >> Pretty much all the phones happily stay charged on a 500mA USB port.
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Oct 10, 2013 at 10:07 AM, Mike Billau 
> >> wrote:
> >>
> >> > Hi Sergey,
> >> >
> >> > We have been using David's Medic++ over here without too many issues.
> >> > (Moving the master to a linux box was key.) The setup was pretty easy
> >> once
> >> > you get Buildbot installed.
> >> >
> >> > I'm not sure how much effort it would take to add Windows platforms
> >> > support, but it doesn't seem like that much. I think that you pretty
> much
> >> > just need to follow the examples of the other two platforms and write
> >> > BuildBot commands (in Python) to shell out to the lower level dev
> tools
> >> to
> >> > create the project and deploy on your devices:
> >> > https://github.com/drkemp/bb-test/blob/master/master.cfg#L132
> >> >
> >> > I think the next steps should be something like:
> >> >
> >> > 1. Set up a centralized couchDB where we can aggregate data from all
> of
> >> the
> >> > CI instances. A few months ago I requested a VM for this purpose and
> it
> >> > looks like we will get it soon:
> >> > https://issues.apache.org/jira/browse/INFRA-6422
> >> > 2. Need a dashboard to view all of the results
> >> > 3. Set up reporting so that the CI actually gets used (email devs who
> >> break
> >> > builds, possibly IRC bot, would be nice to have a TravisCI style
> badge on
> >> > the github pages, etc.)
> >> > 4. Documentation - there should at least be instructions to help
> others
> >> > quickly set up a CI and feed data back to the community (David's
> >> readme.md
> >> > ?)
> >> > There should also be docs about setting up the device wall, which USB
> >> hubs
> >> > are the best to buy*, etc
> >> >
> >> > After those three immediate issues get resolved, I think the CI will
> >> start
> >> > to really provide a lot of value to the community and the project.
> After
> >> > that happens, we can talk about more long term goals and feature
> >> > enhancements. The biggest enhancement I can think of would be the
> ability
> >> > to run personal builds against the test devices and get feedback
> before
> >> > checking in code. I'm sure there are a lot of other things we can do
> too,
> >> > like adding in the rest of the platforms, exercising the native tests,
> >> > making the system more robust, etc.
> >> >
> >> > David, what do you think about pushing your bb-test branch into the
> >> > cordova-medic repo? We can put Fil's old stuff into a branch for safe
> >> > keeping, but it seems like we should all be concentrating on the same
> >> > version of medic, and your buildbot branch is clearly the most
> complete
> >> and
> >> > working version. Having it in the official repo would make it easier
> for
> >> > people to find and contribute to.
> >> >
> >> > Mike Billau
> >> >
> >> > *For USB hubs, we have been daisy chaining these hubs and have only
> had
> >> > charging issues with Samsung tablets:
> >> >
> >>
> http://www.amazon.com/Plugable-Charger-Adapter-Charges-Kindle/dp/B005P2BY5I
> >> >
> >> > David has been using these ones that have a 2.1A port for iPad
> charging
> >> (we
> >> > haven't yet seen the iPads discharge ):
> >> >
> >> >
> >>
> http://www.amazon.ca/Release-Charging-Adapter-3-5-foot-Included/dp/B00B7FLPBU/ref=cm_cr_pr_product_top
> >> > I think part of the medic documentation should definitely have a
> >> discussion
> >> > about USB hubs because this is a difficult and potentially very
> expensive
> >> > part of setting up medic.
> >> >
> >> >
> >> > On Thu, Oct 10, 2013 at 9:47 AM, David Kemp 
> wrote:
> >> >
> >> > > Hi Sergey,
> >> > > Yes that is the only change to mobilespec regarding medic. It simply
> >> > allows
> >> > > the automated test components to be installed as a plugin without
> >> editing
> >> > > any source files other than config.xml.
> >> > >
> >> > > There is a separate discussion going on about changing mobilespec
> to a
> >> > > wrapper that gets tests out of plugins (since thats mostly what it
> >> > tests),
> 

Medic development effort consolidation

[Lorin Beer]

Hey folks,


Adobe's device testing monolith, the Device Wall, has arrived from
Vancouver and we are setting up our continuous integration and testing
system in SF.

I think its time to formalize a plan for running CI testing nodes, and
aggregating the results.

Currently, I believe Adobe, Google, IBM, and BlackBerry are all running
instances of medic.


The first question to ask is what version should we concentrate on going
forward.

The Cordova Apache medic repo (
https://git-wip-us.apache.org/repos/asf/cordova-medic.git) has gotten a
little stale, and hasn't seen active development in sometime

David Kemp has a CI framework as well. My understanding is that it is
partially based on Fil's medic, but is not a direct fork and hasn't been
developed with community input.
https://github.com/drkemp/bb-test


thoughts?

- Lorin

Re: Want to contribute

[Lorin Beer]

you've taken the first step by emailing de-subscr...@cordova.apache.org.

The second step should be to sign the CLA. You can read about it and the
contributor workflow here:
 
http://wiki.apache.org/cordova/ContributorWorkflow

Once you've signed and submitted your CLA, feel free to browse currently
open issues on the project here: https://issues.apache.org/jira/browse/CB
https://issues.apache.org/jira/browse/CB

If you see an issue you are interested in, just ping the assignee to get
any background information, and you can ask the list if you need any help.



Thanks for your interest and we welcome your first contribution!

- Lorin


On Thu, Sep 19, 2013 at 10:53 AM, Naik, Archana  wrote:

> Hello, Cordova Devs,
>
> I would like to subscribe to Cordova as a dev and contribute possibly in
> near future. Please add me to these mailing list.
>
>
> Thanks
> Archana
>

Re: 3.1 Release

[Lorin Beer]

I was away a good chunk of yesterday due to a sick wife, getting BB tagged
today. Sorry for the delay.


On Thu, Sep 19, 2013 at 9:59 AM, Shazron  wrote:

> Sorry for the iOS release guys I'm getting it out today
>
>
> On Thu, Sep 19, 2013 at 8:00 AM, Michal Mocny  wrote:
>
> > Specifically, I think the section "Branch & Tag RC1 for Platform
> > Repositories"
> >
> >
> > On Thu, Sep 19, 2013 at 7:59 AM, Michal Mocny 
> wrote:
> >
> > > I think its this one: http://wiki.apache.org/cordova/CuttingReleases
> > >
> > >
> > > On Thu, Sep 19, 2013 at 7:52 AM, Jeffrey Heifetz <
> > jheif...@blackberry.com>wrote:
> > >
> > >> I can take the responsibility of tagging BlackBerry. Could you send me
> > >> the wiki with instructions ?
> > >>
> > >> From: Andrew Grieve mailto:agri...@chromium.org
> >>
> > >> Date: Thursday, 19 September, 2013 10:40 AM
> > >> To: dev mailto:dev@cordova.apache.org>>,
> > Jeffrey
> > >> Heifetz mailto:jheif...@blackberry.com>>
> > >> Subject: Re: 3.1 Release
> > >>
> > >> +Jeffrey - maybe you could take on the BlackBerry component for this
> > >> release?
> > >>
> > >>
> > >> On Thu, Sep 19, 2013 at 10:00 AM, Michael Brooks <
> > >> mich...@michaelbrooks.ca> wrote:
> > >> Once the platforms are tagged, I can handle the docs. I'll need to
> > review
> > >> our release process and see how the docs can best abide by them.
> > >>
> > >>
> > >> On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve  > >> > wrote:
> > >>
> > >> > Shaz - Thanks for the update :). If iOS is the last one then I'd say
> > >> let's
> > >> > go without, but maybe keep at it until we get BB tagged? (just my
> > >> opinion)
> > >> >
> > >> > Heading home now - anyone know if Lorin is away or not?
> > >> >
> > >> >
> > >> > On Wed, Sep 18, 2013 at 3:35 PM, Shazron  > >> shaz...@gmail.com>> wrote:
> > >> >
> > >> > > When i mean ios-deploy still works, it _installs_ it on the
> device,
> > >> but
> > >> > > does _not_ run it.
> > >> > >
> > >> > >
> > >> > > On Wed, Sep 18, 2013 at 12:31 PM, Shazron  >  > >> shaz...@gmail.com>> wrote:
> > >> > >
> > >> > >> I'm 99% done with iOS specific fixes. One last one I'm trying to
> do
> > >> is
> > >> > >> ios-deploy with lldb:
> > https://issues.apache.org/jira/browse/CB-4804
> > >> > >>
> > >> > >> This means if I don't get this fix in, we _can_ deploy from the
> > >> command
> > >> > >> line using ios-deploy _but_ we can't attach to the debugger. Will
> > >> that
> > >> > be
> > >> > >> acceptable you think?
> > >> > >>
> > >> > >>
> > >> > >> On Wed, Sep 18, 2013 at 12:07 PM, Andrew Grieve <
> > >> agri...@chromium.org
> > >> > >wrote:
> > >> > >>
> > >> > >>> Ping Lorin & Shaz.
> > >> > >>>
> > >> > >>>
> > >> > >>> On Wed, Sep 18, 2013 at 2:19 AM, Steven Gill <
> > >> stevengil...@gmail.com
> > >> > >wrote:
> > >> > >>>
> > >> >  FFOS will be tagged tomorrow. I have a few changes I am going
> to
> > >> get
> > >> > in
> > >> >  tomorrow before tagging but it will be good to go very soon!
> > >> > 
> > >> >  With FFOS, Only two plugins have been ported so far (vibration
> > and
> > >> >  device).
> > >> >  We are going to continue to add firefoxos support to plugins
> post
> > >> >  release.
> > >> >  I don't think we should start officially promoting support for
> > FFOS
> > >> >  until
> > >> >  we have more plugins. For 3.1, it will be available for users
> to
> > >> try
> > >> >  out,
> > >> >  test, give feedback, etc.
> > >> > 
> > >> >  Cheers,
> > >> >  -Steve
> > >> > 
> > >> > 
> > >> >  On Tue, Sep 17, 2013 at 7:38 PM, Andrew Grieve <
> > >> agri...@chromium.org>
> > >> >  wrote:
> > >> > 
> > >> >  > Thanks Jesse! Great work on being on top of things. If
> changes
> > >> were
> > >> >  done in
> > >> >  > plugin repos, then those aren't a part of this release
> anyways
> > >> and
> > >> >  will be
> > >> >  > picked up by the RELEASENOTES.md within the plugin repos on
> the
> > >> next
> > >> >  > plugins release.
> > >> >  >
> > >> >  > I think it's up to you if you want to start writing
> > >> RELEASENOTES.md
> > >> >  for
> > >> >  > WP7+8. My thinking was just that doing so would make release
> > >> >  announcements
> > >> >  > easier.
> > >> >  >
> > >> >  > Since WP7 and WP8 are in the same repo, does it make sense to
> > >> have
> > >> >  > different subtasks for their taggings? If so, I'll add it to
> > the
> > >> >  template,
> > >> >  > if not, maybe I'll just change WP8 to say WP7+WP8? WDYT?
> > >> >  >
> > >> >  > Shaz - I see you're still checking in iOS7 fixes. Do you
> think
> > >> > you'll
> > >> >  be
> > >> >  > able to tag iOS / OSX soon?
> > >> >  > Lorin - Same question for BB. Will you be able to write an
> > update
> > >> >  script

Re: Proposal: Change JIRA to have bugs as "unassigned" by default

[Lorin Beer]

apology already posted, but I'll reiterate that 12 hours for a process
change that affects all assignees is way to short, especially on a project
with contributors across the globe.


On Thu, Sep 19, 2013 at 9:29 AM, Andrew Grieve  wrote:

> Sorry for jumping the gun - figured this would be an easy thing the change
> back if people started -1ing. Also don't think we necessarily need all
> components to work the same. I'm specifically only interested in the
> components that I do triage on: Android, iOS, Mobile Spec, JS, Plugins.
>
> Jesse - What's your rationale for wanting it to stay the way it was before?
> (I've changed the windows ones back)
>
> Joe - I also spend a lot of time triaging bugs as they come in. I've been
> doing it for many months now. I think it's fine for anyone to triage,
> because often the best person to do so changes depending on the bug. I
> actually think having an explicit triage step will make our project seem
> more alive, since people will see action taken on their bugs (adding an
> assignee).
>
> Marcel - I like your JIRA states that you've listed out. I think it's
> important for JIRA to contain this amount of state for the components that
> have several people in different places working on them.
>
>
>
>
> On Thu, Sep 19, 2013 at 12:09 PM, Marcel Kinard 
> wrote:
>
> > This sounds like a solution to workflow issue. But what is our workflow?
> >
> > So if I understand correctly, the proposal is that a new bug that is
> > unassigned means it has not been triaged.
> >
> > What would Jira state be for the following:
> > - triaged and nobody plans to work on it yet (low priority)
> > - triaged and person X plans to work on it, but they haven't started yet
> > (person X's to do list)
> > - triaged and person X plans to work on it, and they have started (in
> > progress)
> >
> > And do these states need to be captured in Jira or is that overkill?
> >
> > Is it expected that the component owner does all the triage-ing?
> >
> >
> > On Sep 18, 2013, at 11:00 PM, Andrew Grieve 
> wrote:
> >
> > > Motivation:
> > > It's impossible to know whether new bugs have been looked at by the
> > default
> > > assignee.
> > >
> > > Rationale:
> > > Setting it to , means new bugs will be obviously
> "untriaged".
> > > Once assigned, it will mean someone intends to work on it.
> > >
> > > This won't eliminate bugs that get assigned and then not fixed in a
> > timely
> > > fashion. I think that's okay though. It'll be an improvement anyways.
> >
> >
>

Re: [Android] Adding init() to the template and decoupling from loadUrl

[Lorin Beer]

reviewing the issue, I don't see any problem with this fix. Sounds
reasonable to me.


On Wed, Sep 11, 2013 at 1:24 PM, Joe Bowser  wrote:

> This is in response to CB-4620:
>
> This bug only happens if you are switching between pages faster than
> the app can draw the URI.  I don't even know how this could happen,
> since I didn't think the WebView worked without being attached to a
> view, but it does.
>
> So, what I'm proposing is that we add an init() call to the template
> so that the layout is initialized before we load URLs? Is there a
> reason to not do this? Does this break anything?
>
> Joe
>

Re: Introduction

[Lorin Beer]

welcome, Mark!


On Tue, Aug 27, 2013 at 9:25 AM, Brian LeRoux  wrote:

> Welcome to the battle Mark!
>
>
> On Tue, Aug 27, 2013 at 7:52 AM, Filip Maj  wrote:
>
> > Welcome Mark!
> > On 2013-08-27 7:49 AM, "Mark Koudritsky"  wrote:
> >
> > > Hi All,
> > >
> > > I just wanted to introduce myself. I'm joining the Cordova team at
> > Google.
> > > So far signed the ICLA, signed up for a JIRA account and got this bug
> to
> > > start from:
> > > https://issues.apache.org/jira/browse/CB-4622
> > >
> > > My previous project was with the ChromeOS AutoTest lab.
> > > Looking forward to contributing to Cordova.
> > >
> > >  - Mark
> > >
> >
>

Re: Post 3.0 release committer and community meeting

[Lorin Beer]

Congrats!


On Wed, Aug 21, 2013 at 1:12 PM, Michael Brooks wrote:

> Congrats Lucas!
>
>
> On Wed, Aug 21, 2013 at 11:07 AM, Tommy Williams 
> wrote:
>
> > Congrats!!
> > On 21 Aug 2013 23:56, "Lucas Holmquist"  wrote:
> >
> > > I want to say sorry,  i was signed up and didn't attend.  My wife was
> due
> > > in september, but the little guy had other plans and came early,  so
> this
> > > totally slipped my mind
> > > On Aug 19, 2013, at 10:30 AM, Andrew Grieve 
> > wrote:
> > >
> > > > Really enjoyed the hangout. We had ~100 views according to youtube
> > (can't
> > > > figure out how to make the view count visible...). For a good time
> > > > (waster), watch some of it with closed captioning enabled :)
> > > >
> > > >
> > > > On Wed, Aug 14, 2013 at 7:36 PM, Andrew Grieve  >
> > > wrote:
> > > >
> > > >> Here's the view link for all listeners!
> > > >>
> > > >> http://youtu.be/bnO7hkWkv5w
> > > >>
> > > >> Feel free to chat on IRC as well (#cordova)
> > > >>
> > > >>
> > > >> On Wed, Aug 14, 2013 at 6:05 PM, Filip Maj  wrote:
> > > >>
> > > >>> Andrew, can you update the Adobe Vancouver colocation circle/invite
> > > thing
> > > >>> with my ID instead of Al's?
> > > >>>
> > > >>> On 8/14/13 9:28 AM, "Michal Mocny"  wrote:
> > > >>>
> > >  Keep in mind that everyone will be able to watch this live or
> > recorded
> > >  later.  You only need a direct invite if you would like to speak.
> > > 
> > > 
> > >  On Wed, Aug 14, 2013 at 11:58 AM, Lisa Seacat DeLuca
> > >  wrote:
> > > 
> > > > Is it too late to get invited to this?  ldeluca.  I'm not
> colocated
> > > but
> > > > I
> > > > did add you to my G+ account!
> > > >
> > > >
> > > > Lisa Seacat DeLuca
> > > > ldel...@apache.org
> > > >
> > > > - Message from Andrew Grieve  on Wed,
> 14
> > > Aug
> > > > 2013 11:44:48 -0400 -
> > > > To:
> > > > dev 
> > > > Subject:
> > > > Re: Post 3.0 release committer and community meeting
> > > > Reminder to let me know which person from each co-lo to invite!
> > > >
> > > > Right now I have a Circle with:
> > > >
> > >  agrieve, co-location=Google Waterloo
> > >  aharding, co-location=Adobe Vancouver
> > >  jheifetz, co-location=BlackBerry Toronto
> > >  devgeeks, co-location=n/a Melbourne, Australia
> > >  aogilvie, co-location=n/a Tokyo, Japan.
> > >  jamesjong, co-location=IBM Raleigh
> > >  lucasholmquist, co-location=Red Hat, Upstate New York
> > >  lorinbeer, co-location=Adobe San Francisco
> > > >
> > > >>>
> > > >>>
> > > >>
> > >
> > >
> >
>

Re: PROPOSAL: node.js all the script things

[Lorin Beer]

this conversation has been continuing on and offline around the watercooler.

+1 for Jesse's concern.

There is absolutely no value in throwing out working bat scripts and
rewriting them in node. It's makework.

For BB10, the scripts were written in node in the first place, and bash/bat
scripts invoke the node scripts. The inverse would be fine for WP7/8. Node
alias invokes bat script.


On Wed, Aug 7, 2013 at 12:51 PM, Jesse  wrote:

> No, I have not yet seen it, sounds sweet, and I applaud your commitment.
> The comment was based on historical data; I am still optimistic for the
> future.
> You will of course need to upgrade/downgrade to Windows 8 to develop/test
> for Windows 8, or Windows Phone 8.
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Aug 7, 2013 at 12:14 PM, Filip Maj  wrote:
>
> > I resent that comment about lack of Windows testing! Have you seen my
> > sweet swivel-monitor laptop that I have Windows 7 on?
> >
> > On 8/7/13 12:11 PM, "Jesse"  wrote:
> >
> > >Well, given that only Benn, and myself have contributed to the windows
> 8,
> > >and windows phone platform scripts, and no one else even seems willing
> to
> > >test the windows phone platform, it seems unfair to suggest we throw
> away
> > >working code, and rewrite it just for fun.
> > >
> > >Having a dependency on node is not a big deal, it is the 30+ other npm
> > >libraries that always seem to come along, each with varying support for
> > >windows, that I have issues with.
> > >
> > >I will consider writing you a node callable facade, that still calls the
> > >.bat and wsh files behind the scenes.
> > >
> > >
> > >
> > >@purplecabbage
> > >risingj.com
> > >
> > >
> > >On Wed, Aug 7, 2013 at 11:40 AM, Steven Gill 
> > >wrote:
> > >
> > >> To install any plugins you at least need plugman which requires node.
> > >>Our
> > >> users are most likely going to have to install node as a dependency at
> > >>some
> > >> point. I don't see why having it as a dependency for platform
> libraries
> > >>is
> > >> such a big deal.
> > >>
> > >>
> > >> On Wed, Aug 7, 2013 at 11:34 AM, M. Lantz 
> wrote:
> > >>
> > >> > +1
> > >> >
> > >> > Agreed I pretty much only use Cordova cli at this stage to make apps
> > >>and
> > >> > as such don't have any issues keeping my node up to date or relying
> > >>on is
> > >> > as a dependency.
> > >> >
> > >> > M. Lantz
> > >> >
> > >> > On 2013-08-07, at 1:07 PM, Frank Hennig 
> > >> wrote:
> > >> >
> > >> > > +1 for all platforms
> > >> > >
> > >> > > I think it's not really an completely new dependency. Some
> > >>components
> > >> > actually depends on node.js like cordova-cli and plugman. Many
> > >>developers
> > >> > of cordova app's actually using grunt or bower and other node
> related
> > >> stuff
> > >> > to lint or to test their html and js code.
> > >> > >
> > >> > > A consistent tool and script language it's easier to maintain an
> to
> > >> > debug.
> > >> > >
> > >> > >
> > >> > > On Aug 7, 2013, at 12:14 AM, Filip Maj wrote:
> > >> > >
> > >> > >> I would like to introduce node.js as a dependency for the
> platform
> > >> > >> libraries, so that the platform scripts (bin/create, cordova/run,
> > >>etc)
> > >> > are
> > >> > >> written in node.
> > >> > >>
> > >> > >> Pros:
> > >> > >> - For multi-OS platforms (Android, BlackBerry), this reduces
> > >>committer
> > >> > >> cognitive load as the scripts do not need to be authored in two
> > >> > different
> > >> > >> script languages (I.e. Shell for unix-y Oses, Wscript for
> Windows)
> > >> > >> - consistency in tool/script language. Cordova-js, coho, cli and
> > >> plugman
> > >> > >> are all written on top of node.js.
> > >> > >>
> > >> > >> Cons:
> > >> > >> - Introducing a new dependency
> > >> > >>
> > >> > >> NB: This is separate from platform-spec; I would like to see
> > >> > platform-spec
> > >> > >> created/used regardless of the outcome of this thread.
> > >> > >
> > >> >
> > >>
> >
> >
>

Re: Versioning in a 3.0 world

[Lorin Beer]

1&2 don't agree, if I understand correctly
While strict semver is fine for more homogenous projects, I feel the
versioning system in Cordova must reflect more. For one thing, linking the
different platforms together in terms of compatibility and supported
features. Otherwise, things seem far too fragmented; as much as possible
the major and minor versions should line up for the platforms. No one
should have to consult a chart to determine feature compatibility between
platforms. The version number should immediately inform this.

5. agree, this allows plugins to progress as needed, and independently

On Mon, Aug 12, 2013 at 7:56 AM, Braden Shepherdson wrote:

> This was starting to come up in another thread, but since I think this is a
> separate issue I wanted to raise the discussion here instead.
>
> We need to decide how we're going to manage releases, versioning and
> compatibility between plugins, platforms and tools, in the new 3.0 world.
>
> (tl;dr at the bottom)
>
> There are several related questions here:
>
> 1. Do all platforms releases 3.x.0 together?
> 2. On a monthly cadence or by features or what other criteria?
> 3. Are plugin releases fully independent of Cordova releases? Are the
> plugin version numbers fully decoupled from Cordova versions?
> 4. Are we using semver? For what? If so, that has implications for the
> deprecation policy and breaking changes.
>
>
> There are several different ways we could go here. I'm going to outline my
> vision for how we answer these questions, but there are certainly other
> approaches.
>
> My main premise is that each individual component will be much, much more
> stable than any platform was in the old days. This is especially true of
> the platforms: they contain little besides bridge and startup code now, and
> that has been quite stable. Most plugins change infrequently, when bugs are
> discovered, the specs evolve, and new OS versions are released. I suspect
> the majority of them will have no changes in a given month. Some are less
> stable, of course. (FileTransfer, I'm looking at you >:-|)
>
> From this basis, I propose the following plan:
>
> 1. Things are versioned independently, and we use semver for everything.
> That means the plan for 3.x up to Cordova 4.0 is still sound, but the
> version numbers probably won't line up as in the plan. We'll bump the major
> versions of every component whenever they have breaking changes, as semver
> specifies.
>
> 2. No release cadence anymore: things release when they're ready. See #3,
> though.
>
> 3. Instead of keeping the platforms synced in time, I propose a stronger
> condition: we attach meaning to platform versions (but not plugin or tool
> versions). I mean: Platforms can't release a 3.3.0 until they support
> whatever new feature it was that caused the bump from 3.2.x (see above re:
> semver).
>
> 4. Meanwhile, the tools are still attached to Cordova versions, as
> discussed elsewhere, and have versions like 3.3.0-0.12.2.
>
> 5. Plugins have unrestricted version numbers; nothing wrong with installing
> batterystatus 3.1.2 alongside filetransfer 8.4.3, targeting iOS and Android
> 3.3.x.
>
> We have the tools and we specify version constraints, and I suggest that
> these be how we keep versions in sync, not organizational rules about
> releases. If, for example, a plugin (whatever its version number) depends
> on a bridge feature added in Cordova 3.3.0, it can specify that in its
>  tags.
>
> The big advantage in my mind is that this model gives everyone a lot more
> flexibility. We can update, deprecate and remove things whenever it's time
> to. We can leave deprecation warnings in for as long as feels appropriate,
> and then bump the major version and remove them. For our users, they can
> depend on the old behavior of some plugin, and specify an old version of
> it, but they can get the latest versions of everything else, including the
> platform and tools, at least until they hit a new major version.
>
>
> tl;dr: fully independent releases of everything, no schedule, semver for
> everything. Tools and platforms share version numbers, but in the sense
> that "you can't be a 3.3.0 platform until you have new feature X"; they
> don't release at the same time.
>
>
> Braden
>

Re: Post 3.0 release committer and community meeting

[Lorin Beer]

agrieve, co-location=Google Waterloo
mmocny, co-location=Google Waterloo
maxw, co-location=Google Waterloo
aharding, co-location=Adobe Vancouver
filmaj, co-location=Adobe Vancouver
stevegill, co-location=Adobe Vancouver
bhiggins, co-location=BlackBerry Toronto
jheifetz, co-location=BlackBerry Toronto
devgeeks, co-location=n/a Melbourne, Australia
aogilvie, co-location=n/a Tokyo, Japan.
drkemp, co-location=Google Waterloo
iclelland, co-location=Google Waterloo
jamesjong, co-location=IBM Raleigh
kwallis, co-location=n/a near-Toronto, Canada
purplecabbage, co-location=Adobe Vancouver
lucasholmquist, co-location=Red Hat, Upstate New York
lorinbeer, co-location=Adobe San Francisco


updated at Steve's request. Steve will be in Vancouver that week.


On Wed, Aug 7, 2013 at 12:09 PM, Filip Maj  wrote:

> That's it for hangout participants, then.
>
> On 8/7/13 12:01 PM, "dguald...@gmail.com"  wrote:
>
> >Dgualdron, co-location=n/a Bucaramanga, Colombia
> >
> >Sent from my BlackBerry® wireless device
> >
> >-Original Message-
> >From: Ken Wallis 
> >Date: Wed, 7 Aug 2013 16:06:25
> >To: dev@cordova.apache.org
> >Reply-To: dev@cordova.apache.org
> >Subject: RE: Post 3.0 release committer and community meeting
> >
> >Bringing the list to the top and adding myself:
> >
> >agrieve, co-location=Google Waterloo
> >mmocny, co-location=Google Waterloo
> >maxw, co-location=Google Waterloo
> >aharding, co-location=Adobe Vancouver
> >filmaj, co-location=Adobe Vancouver
> >stevegill, co-location=Adobe San Francisco
> >bhiggins, co-location=BlackBerry Toronto
> >jheifetz, co-location=BlackBerry Toronto
> >devgeeks, co-location=n/a Melbourne, Australia
> >aogilvie, co-location=n/a Tokyo, Japan.
> >drkemp, co-location=Google Waterloo
> >iclelland, co-location=Google Waterloo
> >jamesjong, co-location=IBM Raleigh
> >kwallis, co-location=n/a near-Toronto, Canada
> >
> >--
> >
> >Ken Wallis
> >
> >Senior Product Manager ­ WebWorks
> >
> >BlackBerry
> >
> >650-620-2404
> >
> >
> >From: Shazron [shaz...@gmail.com]
> >Sent: Wednesday, August 07, 2013 11:17 AM
> >To: dev@cordova.apache.org
> >Subject: Re: Post 3.0 release committer and community meeting
> >
> >Ditto - will try to call in since it's at a sane 7:30 am here (audio only
> >most like). The show must go on
> >
> >
> >On Wed, Aug 7, 2013 at 11:02 PM, Joe Bowser  wrote:
> >
> >> I can't make this meeting. I'm out of the office until the 16th.
> >> On Aug 7, 2013 8:06 AM, "James Jong"  wrote:
> >>
> >> > On Aug 7, 2013, at 9:19 AM, Ian Clelland 
> wrote:
> >> >
> >> > >>
> >> > >>> Attendees: If you plan to attend, could you add your name to this
> >> list
> >> > >>> (inline so that the list grows) and say whether you plan to be
> >> > >> co-located:
> >> > >>> agrieve, co-location=Google Waterloo
> >> > >>> mmocny, co-location=Google Waterloo
> >> > >>> maxw, co-location=Google Waterloo
> >> > >>> aharding, co-location=Adobe Vancouver
> >> > >>> filmaj, co-location=Adobe Vancouver
> >> > >>> stevegill, co-location=Adobe San Francisco
> >> > >>> bhiggins, co-location=BlackBerry Toronto
> >> > >>> jheifetz, co-location=BlackBerry Toronto
> >> > >>> devgeeks, co-location=n/a Melbourne, Australia
> >> > >>> aogilvie, co-location=n/a Tokyo, Japan.
> >> > >>> drkemp, co-location=Google Waterloo
> >> > >>
> >> > >> iclelland, co-location=Google Waterloo
> >> > >> jamesjong, co-location=IBM Raleigh
> >> > >
> >> > >
> >> > >
> >> > >> Agenda (feel free to add items inline):
> >> > >>
> >> > >>> - Release artifacts and process redux
> >> > >>> - Should platform releases still be coupled?
> >> > >>> - Does semver make more sense to us now that components are more
> >> > >> decoupled?
> >> > >>> - Deprecation policy improvements?
> >> > >>> - Can we use cordova-registry to allow older versions of things
> >>when
> >> > >> APIs are removed?
> >> > >>> - Can we have our plugin API surface versioned separately from our
> >> > >> component versions?
> >> > >>> - Shortterm plans for Medic
> >> > >>> - Buildbot?
> >> > >>> - Should mobile-spec autotests be pulled out?
> >> > >>> - 4.0 goals, timeline, and priorities
> >> > >>> - Platforms as build artifacts - Is this our goal? what's
> >> > >> big hurdles remain?
> >> > >>> - Apps & Plugins to have the same feature set (dependencies,
> >>merges/,
> >> > >> etc)
> >> > >>
> >> >
> >> >
> >>
> >
> >-
> >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 transmissi

Re: PROPOSAL: node.js all the script things

[Lorin Beer]

+1 for Android/BB

would be majorly helpful on those platforms


On Wed, Aug 7, 2013 at 9:15 AM, Filip Maj  wrote:

> I agree with you, Andrew.
>
> Bryan, judging by this thread, it doesn't look like we'll be switching
> over to node.js for all platforms, just for android/bb.
>
> On 8/7/13 7:38 AM, "Andrew Grieve"  wrote:
>
> >I should also add that when I installed node on windows XP, it had no
> >other
> >dependencies and was far easier to install than android's other
> >dependencies (android sdk, eclipse, JDK).
> >
> >However, I did also find that at least one of node's apis (getline) didn't
> >work on windows. We'll have to still test on all platforms for most
> >changes.
> >
> >I think it'd also be a good idea to either not use any npm dependencies,
> >or
> >to commit the node_modules directory if we do. That way our users don't
> >need to worry about running "npm install"
> >
> >
> >On Wed, Aug 7, 2013 at 10:36 AM, Andrew Grieve 
> >wrote:
> >
> >> +1 for Android.
> >>
> >>
> >> On Wed, Aug 7, 2013 at 10:00 AM, Bryan Higgins
> >>wrote:
> >>
> >>> All BB scripts are already written in node, except for check_reqs. It's
> >>> hard to check for the existence of node using node. :)
> >>>
> >>> If other platforms go that way, we should standardize the location of
> >>>the
> >>> scripts. I'd like to see them directly invoked by CLI rather than going
> >>> through the shell.
> >>>
> >>>
> >>> On Tue, Aug 6, 2013 at 7:24 PM, Anis KADRI 
> >>>wrote:
> >>>
> >>> > +1 if we can somehow automate a user-level node installation (or
> >>> > package it somehow).
> >>> >
> >>> > On Tue, Aug 6, 2013 at 3:28 PM, Filip Maj  wrote:
> >>> > > That's a fair answer! I concur. The main win for me is in android
> >>>+ BB
> >>> > > land, for the reason you name, Jesse.
> >>> > >
> >>> > > On 8/6/13 3:24 PM, "Jesse"  wrote:
> >>> > >
> >>> > >>I only think this should be done for the multi-OS platforms.
> >>> > >>Elsewhere it is just a make work project IMHO.
> >>> > >>I have spent a lot of time ensuring that I was not introducing
> >>> > >>dependencies, then we add node, and we get 600 deps.
> >>> > >>
> >>> > >>@purplecabbage
> >>> > >>risingj.com
> >>> > >>
> >>> > >>
> >>> > >>On Tue, Aug 6, 2013 at 3:14 PM, Filip Maj  wrote:
> >>> > >>
> >>> > >>> I would like to introduce node.js as a dependency for the
> >>>platform
> >>> > >>> libraries, so that the platform scripts (bin/create, cordova/run,
> >>> etc)
> >>> > >>>are
> >>> > >>> written in node.
> >>> > >>>
> >>> > >>> Pros:
> >>> > >>> - For multi-OS platforms (Android, BlackBerry), this reduces
> >>> committer
> >>> > >>> cognitive load as the scripts do not need to be authored in two
> >>> > >>>different
> >>> > >>> script languages (I.e. Shell for unix-y Oses, Wscript for
> >>>Windows)
> >>> > >>> - consistency in tool/script language. Cordova-js, coho, cli and
> >>> > plugman
> >>> > >>> are all written on top of node.js.
> >>> > >>>
> >>> > >>> Cons:
> >>> > >>> - Introducing a new dependency
> >>> > >>>
> >>> > >>> NB: This is separate from platform-spec; I would like to see
> >>> > >>>platform-spec
> >>> > >>> created/used regardless of the outcome of this thread.
> >>> > >>>
> >>> > >>>
> >>> > >
> >>> >
> >>>
> >>
> >>
>
>

Re: [plugins] Proper handling of subsequant calls in Media plugin

[Lorin Beer]

I ran into this sometime ago on the android media API. The relevant
conversation is likely deeply buried, and we should consider documenting
the appropriate behavior somewhere permanent.

My opinion is that appropriate behavior is dependent on the function being
called and the current state. A FSM could capture this.
In terms of  during  state, I would recommend that the plugin
executes the latest command normally, playing media from a new source or
restarting the currently executing media as if the play command had been
received in the  state.

- Lorin


On Thu, Aug 1, 2013 at 1:47 PM, Benn Mapes  wrote:

> Working on https://issues.apache.org/jira/browse/CB-3783, it appears that
> there is no documentation on how the media plugin should handle subsequent
> calls of the same function.
>
> An example would be calling my_media.play() multiple times when the
> my_media is already playing. Should this be swallowed by the plugin and
> ignored? Should we respond with a
> MediaError<
> http://cordova.apache.org/docs/en/3.0.0/cordova_media_media.md.html#MediaError
> >.MEDIA_ERR_ABORTED
> and a message saying the media is already playing? What about subsequent
> calls to my_media.pause() when the media is already paused?
>
> Was just wondering what other platforms have implemented for this and what
> the proper way of handling subsequent calls is.
>
> ~Benn
>

Re: Questions regrading Contribution to the Project

[Lorin Beer]

Absolutely.


On Tue, Jul 23, 2013 at 6:05 PM, Andrew Grieve  wrote:

> Makes sense.
>
>
> On Tue, Jul 23, 2013 at 8:26 PM, Filip Maj  wrote:
>
> > Maybe we should consider adding language about assigned JIRA issues, In
> > Progress, etc, to the contribution docs?
> >
> > On 7/23/13 11:20 AM, "Sharif Ahmed"  wrote:
> >
> > >Thank you so much to both Andrew and Lorin. I will go ahead with the
> > >CLA and also proceed with the jira issues.
> > >
> > >Thanks again.
> > >
> > >On 7/23/13, Lorin Beer  wrote:
> > >> Hi Sharif,
> > >>
> > >> the first step is to sign and submit a CLA. You can find more
> > >>information
> > >> here:
> > >>
> > >>http://www.apache.org/licenses/#clas<
> > http://www.apache.org/licenses/#clas
> > >>>
> > >> If you have an issue which is unassigned, and that you're interested
> in
> > >> working on, ping the lead on that platform and discuss workflow and
> > >> procedure!
> > >>
> > >> Thanks for the interest!
> > >>
> > >> - Lorin Beer
> > >>
> > >>
> > >> On Mon, Jul 22, 2013 at 10:29 PM, Sharif Ahmed
> > >> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I am Sharif Ahmed. I want to contribute to the project. I am
> interested
> > >>> in
> > >>> Android and Docs section. I have checked out the jira issues for
> these
> > >>> two
> > >>> sections, and found that there are few issues which are un-assigned.
> > >>> What is the process of assigning me any jira issue?
> > >>> I really want to contribute to the next point releases, 3.1 being the
> > >>> next
> > >>> one in September. How can I get involved in the next point releases?
> > >>>
> > >>> --
> > >>> Regards,
> > >>>
> > >>> Sharif Ahmed
> > >>> Junior Software Engineer
> > >>> Therap Services, LLC
> > >>> +01715438290
> > >>>
> > >>
> > >
> > >
> > >--
> > >Regards,
> > >
> > >Sharif Ahmed
> > >Junior Software Engineer
> > >Therap Services, LLC
> > >+01715438290
> >
> >
>

Re: cordova-app-harness and the App Store

[Lorin Beer]

I agree with your breakdown of options in order of sanity, Braden :)

Ideally this should be owned by the organization that owns the code: the
Apache Cordova Project. While an acceptable second would be for the Adobe
Cordova Team to publish it, I think there is a precedent for an Apache
project owning and managing an appstore account.

Apache OpenOffice is made available through the mac appstore.

- Lorin


On Tue, Jul 23, 2013 at 9:37 AM, Braden Shepherdson wrote:

> So we've got a working app harness in the cordova-app-harness repo. One of
> the founding goals for the app harness was that it could be placed into the
> Play Store and App Store.
>
> Then the question is: who owns the apps in the various markets? It seems to
> me that there are four possibilities:
>
> 1. Apache Cordova project (Can we do that under Apache's rules? Apple's
> rules? Is there precedent at Apache for App Store accounts and such?)
>
> 2. Adobe PhoneGap team
> 3. Google Cordova/Mobile Chrome Apps team
> (4. Some individual person from one of the above, separately from the
> larger organization.)
>
> These are in descending order of how sane I think they are. If it's
> possible for the Apache project to control the AppStore accounts, that
> would be best. If not, the PhoneGap team is probably the best way to go.
>
> Thoughts?
>
> Braden
>

Re: cordova-playbook 'deprecation'

[Lorin Beer]

doubtful Gord,

I think the promise of PlayBook support alongside BlackBerry10 Support was
contingent on porting BB10 to the playbook. My understanding is that this
is considered infeasible due to the ram requirements of BB10.

One way or another no one is currently stepping up to the plate to maintain
BBOS and PlayBook.

- Lorin


On Tue, Jul 23, 2013 at 8:37 AM, Gord Tanner  wrote:

> I am just a little annoyed because of the promise that we would get
> PlayBook support with the big BlackBerry 10 rewrite that was done.  The
> promise was we were just shelving the Java Phone OS code and cleaning up
> things for PlayBook and BlackBerry 10.
>
> I hope that the official support for BlackBerry 10 isn't thrown out as
> quickly as PlayBook support was as soon as BlackBerry 11 is released.
>
> Like I said in a previous email, we went from supporting every blackberry
> device in cordova to supporting only 2 devices (Z10 and Q10).
>
> Would the community be as accepting if we said Cordova only supported iOS7
> on the iPhone5?
>
>
> On Tue, Jul 23, 2013 at 11:19 AM, Brian LeRoux  wrote:
>
> > I think, or at least thought, that is what Lorin meant.
> >
> > On Tue, Jul 23, 2013 at 11:07 AM, Anis KADRI 
> wrote:
> > > "Remove" ? No! Just leave the source in there. Somebody might be
> > interested
> > > in it. We can stop shipping it though if we are still doing it.
> > >
> > >
> > > On Tue, Jul 23, 2013 at 8:04 AM, Lorin Beer  > >wrote:
> > >
> > >> Scare-quotes due to playbook never being an officially supported
> > platform.
> > >>
> > >> After discussing playbook with Bryan and Jeff from BlackBerry, a few
> > points
> > >> came up:
> > >>
> > >> 1. BB10 won't be coming to the PlayBook platform
> > >> 2. The work required to bring it up to 3.0 spec is not justified by
> > >> interest or number of devices
> > >> 3. Many would rather see any effort directed to Playbook go towards
> BBOS
> > >> instead, and that is unlikely to happen.
> > >>
> > >> Without further support for the platform, and with that support being
> > >> poorly justified, I suggest the Playbook platform be removed from
> > Cordova.
> > >>
> > >>
> > >> - Lorin
> > >>
> >
>

Re: cordova-playbook 'deprecation'

[Lorin Beer]

yes, that's exactly what I meant. I'm not going to go deleting code to
remove all history of playbook. It will be no longer released as part of
Cordova in future releases.


On Tue, Jul 23, 2013 at 8:19 AM, Brian LeRoux  wrote:

> I think, or at least thought, that is what Lorin meant.
>
> On Tue, Jul 23, 2013 at 11:07 AM, Anis KADRI  wrote:
> > "Remove" ? No! Just leave the source in there. Somebody might be
> interested
> > in it. We can stop shipping it though if we are still doing it.
> >
> >
> > On Tue, Jul 23, 2013 at 8:04 AM, Lorin Beer  >wrote:
> >
> >> Scare-quotes due to playbook never being an officially supported
> platform.
> >>
> >> After discussing playbook with Bryan and Jeff from BlackBerry, a few
> points
> >> came up:
> >>
> >> 1. BB10 won't be coming to the PlayBook platform
> >> 2. The work required to bring it up to 3.0 spec is not justified by
> >> interest or number of devices
> >> 3. Many would rather see any effort directed to Playbook go towards BBOS
> >> instead, and that is unlikely to happen.
> >>
> >> Without further support for the platform, and with that support being
> >> poorly justified, I suggest the Playbook platform be removed from
> Cordova.
> >>
> >>
> >> - Lorin
> >>
>

cordova-playbook 'deprecation'

[Lorin Beer]

Scare-quotes due to playbook never being an officially supported platform.

After discussing playbook with Bryan and Jeff from BlackBerry, a few points
came up:

1. BB10 won't be coming to the PlayBook platform
2. The work required to bring it up to 3.0 spec is not justified by
interest or number of devices
3. Many would rather see any effort directed to Playbook go towards BBOS
instead, and that is unlikely to happen.

Without further support for the platform, and with that support being
poorly justified, I suggest the Playbook platform be removed from Cordova.


- Lorin

Re: blackberry10 build

[Lorin Beer]

Great write up, Matt. Thanks for the feedback!


On Tue, Jul 23, 2013 at 6:56 AM, Matt Lantz  wrote:

> Thanks Bryan and Ken, I'm going to be writing a tutorial or two and
> sending them to Alex Kinsella.
>
>
> Cheers,
>
> Matt Lantz
> Professional Software Developer / Consultant
> http://mattlantz.ca
> (519) 573 - 1002
>
> On 22 July, 2013 at 4:07:17 PM, Ken Wallis (kwal...@blackberry.com) wrote:
>
> Apparently I am getting older faster than I thought, seeing y's where
> there are i's...
>
> Sent from my BlackBerry 10 smartphone.
> From: Ken Wallis
> Sent: Monday, July 22, 2013 1:05 PM
> To: dev@cordova.apache.org; dev@cordova.apache.org
> Reply To: dev@cordova.apache.org
> Subject: Re: blackberry10 build
>
>
> Bryan is the man. Bryan H. that is. :P
>
> Sent from my BlackBerry 10 smartphone.
> From: Brian LeRoux
> Sent: Monday, July 22, 2013 12:41 PM
> To: dev@cordova.apache.org
> Reply To: dev@cordova.apache.org
> Subject: Re: blackberry10 build
>
>
> Wow, this is awesome thanks Bryan!
>
> On Mon, Jul 22, 2013 at 3:32 PM, Bryan Higgins 
> wrote:
> > I've entered the following issues into JIRA and we will be working to
> get
> > them resolved over the next two weeks.
> >
> > Code:
> >
> > - [CB-4273] CLI pass through of command line args
> >
> > - [CB-4340] Query device to get PIN (no longer required in
> > blackberry10.json)
> >
> > - [CB-4342] Auto-detect connected USB device
> >
> > - [CB-4344] Auto-detect started simulator
> >
> > - [CB-4345] Improve error output for common failure scenarios
> >
> > - [CB-4346] Change DEFAULT_BAR_NAME, remove from create script
> >
> > Docs:
> >
> > - [CB-4347] Restore improvements with screen shots / BBNDK path
> instructions
> >
> > - [CB-4349] Add debug token section
> >
> > - [CB-4351] Add project settings section (config.xml)
> >
> >
> > On Mon, Jul 22, 2013 at 11:49 AM, Bryan Higgins 
> > wrote:
>
> >
> >> Matt - thanks for the detailed feedback!
> >>
> >> I'll be entering in JIRAs for the tasks needed to tighten up the bb10
> CLI
> >> experience today.
> >>
> >>
> >> On Mon, Jul 22, 2013 at 11:20 AM, Lucas Holmquist 
> >> wrote:
>
> >>
> >>> Nice write up,
> >>> On Jul 22, 2013, at 11:14 AM, Matt Lantz  wrote:
> >>>
> >>> > Developing a BlackBerry10 App with Cordova 3.0.0
> >>> > 
> >>> >
> >>> > So, I started by downloading all the appropriate developer SDKs from
> >>> BlackBerry. Though in retrospect I suppose I only needed the webworks
> one.
> >>> > After downloading and installing those. I followed the instructions
> >>> ensuring that I had nodejs installed, and performed an installation of
> >>> cordova. I performed the create app which went fine. I decided first
> to
> >>> test run iOS given that I live in an OSX world. I added iOS, made a
> couple
> >>> tweaks and ran it in the simulator flawlessly. Awesome experience.
> >>> >
> >>> > On to BlackBerry. I first attempted to add the blackberry platform.
> It
> >>> responded with no platform. Since I knew a handful of stuff that Gord
> had
> >>> been working on for BlackBerry builds I attempted, qnx, playbook,
> bb10, and
> >>> then blackberry10 that seemed to be the golden key. After getting the
> >>> platform set, I decided to experiment a bit.
> >>> >
> >>> > I ran the build, and understood how it pulled over the www folder
> data
> >>> to the platforms. I had a couple issues with this though. It seemed
> that
> >>> any custom writing I had done in the platform itself (blackberry10)
> was
> >>> overwritten, including the config.xml which meant if I did an upgrade
> to
> >>> the www directory even changed the file config.xml with new name etc
> it
> >>> overwrites the custom stuff I set in the blackberry10 platform, with
> >>> default values of 'WebWorks Application' etc.
> >>> >
> >>> > So I set some details such as name and author and then added some
> text
> >>> to the index.html page of the www directory for the blackberry10
> platform
> >>> directory. Then I decided to test run it on a blackberry device.
> >>> >
> >>> > Since I had previous experience doing this, I got my debug tokens
> and
> >>> got all that set by following the instructions on BlackBerry's
> website.
> >>> This hit a snag in that it appeared I had used a short password.
> >>> BlackBerry's website says that the csjpin must be between 6-10
> alphanumeric
> >>> characters. But it then turns out that WebWorks needs at least 8
> >>> alphanumeric characters. That was a pain, and lots of wasted time but
> I got
> >>> through that.
> >>> >
> >>> > I didn't even bother installing the blackberry emulator since my
> >>> previous experience with it sucked, I decided to try it on a real
> device. I
> >>> had all the tokens in place and attempted to do a build with the
> >>> instructions on the blackberry website. That failed with no signing
> >>> password provided statement. I did some digging very confusingly since
> I
> >>> had set all those details with my signing keys etc according to the
> >

Re: Questions regrading Contribution to the Project

[Lorin Beer]

Hi Sharif,

the first step is to sign and submit a CLA. You can find more information
here: http://www.apache.org/licenses/#clas<http://www.apache.org/licenses/#clas>
If you have an issue which is unassigned, and that you're interested in
working on, ping the lead on that platform and discuss workflow and
procedure!

Thanks for the interest!

- Lorin Beer


On Mon, Jul 22, 2013 at 10:29 PM, Sharif Ahmed wrote:

> Hi,
>
> I am Sharif Ahmed. I want to contribute to the project. I am interested in
> Android and Docs section. I have checked out the jira issues for these two
> sections, and found that there are few issues which are un-assigned.
> What is the process of assigning me any jira issue?
> I really want to contribute to the next point releases, 3.1 being the next
> one in September. How can I get involved in the next point releases?
>
> --
> Regards,
>
> Sharif Ahmed
> Junior Software Engineer
> Therap Services, LLC
> +01715438290
>

Re: 3.0.0 Final

[Lorin Beer]

rock


On Thu, Jul 18, 2013 at 12:20 PM, Steven Gill wrote:

> Lets do the final tag for 3.0.0. Issue at
> https://issues.apache.org/jira/browse/CB-4294
>

Re: Documenting Plugin Spec

[Lorin Beer]

+1


On Tue, Jul 16, 2013 at 11:03 AM, Shazron  wrote:

> +1
>
> On Tuesday, July 16, 2013, Anis KADRI wrote:
>
> > Yes please!
> >
> >
> > On Tue, Jul 16, 2013 at 10:53 AM, Filip Maj >
> > wrote:
> >
> > > Currently exists in the plugman repo.
> > >
> > > Should we set up a sub guide under cordova-docs plugin guides?
> > >
> > >
> >
>

Re: Converting scripts to node

[Lorin Beer]

The primary benefit I see in moving to node based scripts is quality: it's
a lot easier to write and maintain complex scripts with good tests in js
than it is in bash. Even with the reliance on exiting command line tools
like adb.

It also makes contributing to the scripting side far less intimidating. A
Contributors may feel much more comfortable diving into a js node script
than a shell script.

On Fri, Jul 12, 2013 at 10:07 AM, Filip Maj  wrote:

> Main benefit here is abstracting away two scripts for *nix &
> windows-compatible platforms like android and blackberry. BB already uses
> node for those anyways..
>
> On 7/12/13 9:47 AM, "Brian LeRoux"  wrote:
>
> >Most of the scripts themselves shell out to things like adb or
> >whatever so putting another layer of scripting abstraction over top
> >feels unnecessary (to me). I suppose the benefit is that on Android
> >we'd have less code?
> >
> >Are there other benefits?
> >
> >
> >
> >On Thu, Jul 11, 2013 at 6:55 PM, Andrew Grieve 
> >wrote:
> >> Cool!
> >>
> >> I don't think npm is a good idea for them since that will add another
> >> avenue for mistakes to be made. Shelling out to them seems fine. You can
> >> also just require() them if you're sure they aren't going to mess up
> >>you're
> >> apps state (e.g. change your CWD), but shelling out is certainly safer.
> >>
> >>
> >> On Thu, Jul 11, 2013 at 6:24 PM, Filip Maj  wrote:
> >>
> >>> Don't think for android specifically there has been any work on this
> >>>
> >>> On 7/11/13 2:55 PM, "Andrew Grieve"  wrote:
> >>>
> >>> >We talked about unifying on node post 3.0 for our scripts (e.g.
> >>>android
> >>> >create script).
> >>> >
> >>> >Was wondering if anyone had started on this?
> >>>
> >>>
>
>

Re: Jake woes

[Lorin Beer]

HORRIBLE


On Fri, Jun 21, 2013 at 2:43 PM, Jesse  wrote:

> Punishable by death or bunga-bunga, your choice.
>
> @purplecabbage
> risingj.com
>
>
> On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj  wrote:
>
> > noo
> >
> > On 6/21/13 2:01 PM, "Patrick Mueller"  wrote:
> >
> > >It appears you've made a horrible, HORRIBLE mistake with your patch [1],
> > >and deleted the dalek.  HORRIBLE.
> > >
> > >[1]
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a
> > >3a
> > >
> > >ps: I too once tried to delete the dalek, and look what happened to me.
> > >and
> > >the dalek :-(
> > >
> > >
> > >On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes 
> wrote:
> > >
> > >> Could you also update the README?
> > >> https://issues.apache.org/jira/browse/CB-3966
> > >>
> > >> Thanks!
> > >>
> > >>
> > >> On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve 
> > >> wrote:
> > >>
> > >> > Okay, CB-3960 is the tracker.
> > >> >
> > >> >
> > >> > On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz <
> > >> jheif...@blackberry.com
> > >> > >wrote:
> > >> >
> > >> > > +1
> > >> > >
> > >> > > Sent from my BlackBerry 10 smartphone on the Rogers network.
> > >> > > From: Bryan Higgins
> > >> > > Sent: Friday, June 21, 2013 9:39 AM
> > >> > > To: dev@cordova.apache.org
> > >> > > Reply To: dev@cordova.apache.org
> > >> > > Subject: Re: Jake woes
> > >> > >
> > >> > >
> > >> > > +1
> > >> > >
> > >> > >
> > >> > > On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist
> > >> > >> > > >wrote:
> > >> > >
> > >> > > > +1
> > >> > > > On Jun 20, 2013, at 11:20 PM, Steven Gill <
> stevengil...@gmail.com
> > >
> > >> > > wrote:
> > >> > > >
> > >> > > > > +1 Grunt
> > >> > > > >
> > >> > > > >
> > >> > > > > On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve <
> > >> agri...@chromium.org
> > >> > >
> > >> > > > wrote:
> > >> > > > >
> > >> > > > >> I've burned quite a bit of time trying to get it to work, and
> > >>I'm
> > >> a
> > >> > > bit
> > >> > > > >> realizing that it's probably not worth continuing. By
> fiddling
> > >> with
> > >> > > > >> dependencies I can get it to run, but tasks are being run
> > >>multiple
> > >> > > times
> > >> > > > >> when they shouldn't be, and there's no reason I should need
> to
> > >> > fiddle
> > >> > > > the
> > >> > > > >> deps to get it to run.
> > >> > > > >>
> > >> > > > >> So... any objections if I delete Jakefile and replace it with
> > >> > > > >> a Gruntfile.js?
> > >> > > > >>
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >>-
> > >> > > 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.
> > >> > >
> > >> >
> > >>
> > >
> > >
> > >
> > >--
> > >Patrick Mueller
> > >http://muellerware.org
> >
> >
>

Re: Apache VM for Medic's CouchDB

[Lorin Beer]

that would be fantastic!


On Wed, Jun 19, 2013 at 9:59 AM, Filip Maj  wrote:

> Would love to see this, thanks for taking the initiative on this Mike!
>
> On 6/19/13 7:19 AM, "Andrew Grieve"  wrote:
>
> >Sounds great!
> >
> >
> >On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau 
> >wrote:
> >
> >> Hello everyone,
> >>
> >> I have been working the last week on getting medic up and running here
> >>at
> >> our office, and so far things are going pretty well. I would like to
> >>start
> >> contributing our tests back to the community pretty soon. However, I
> >> contacted Fil about flowing our test results back to the CI database,
> >>and
> >> he informed me that unfortunately the EC2 instance has been removed.
> >>
> >> I would like to propose that we have the Apache folks set us up with a
> >> standard Linux VM that we can use to host the CouchDB server to collect
> >> test results. Using an Apache VM seems to be more in the Apache spirit
> >>as
> >> opposed to an EC2 instance. Since it would be more centralized and
> >> community owned, it would potentially make it easier for other groups to
> >> contribute test results. The VM can also serve as a home for any future
> >> dumps or hosted scripts that we need.
> >>
> >> Any thoughts on this? If there are no problems, then can somebody
> >>involved
> >> with ASF help me create the relevant INFRA issues?
> >>
> >> Thanks,
> >> Mike Billau
> >>
>
>

Re: Release Bugs

[Lorin Beer]

cloning the issue is a good solution, but I suggest updating the script to
reflect Andrew's changes to the release issues.


On Tue, Jun 18, 2013 at 10:08 AM, Andrew Grieve wrote:

> New release bug: https://issues.apache.org/jira/browse/CB-3906
>
>
> On Tue, Jun 18, 2013 at 1:02 PM, Andrew Grieve 
> wrote:
>
> > Okay, I'm going to close out the auto-created ones and create new ones
> for
> > 2.9 before too much action happens
> >
> >
> > On Tue, Jun 18, 2013 at 1:49 AM, Anis KADRI 
> wrote:
> >
> >> On Mon, Jun 17, 2013 at 6:42 PM, Andrew Grieve 
> >> wrote:
> >>
> >> > The bug you created: https://issues.apache.org/jira/browse/CB-3857
> >> > - includes platforms that we're not releasing right now
> >> >
> >>
> >>
> >> Which means I get spammed for no reason :-)
> >>
> >
> >
>

Re: 2.9.0rc1 this coming monday??

[Lorin Beer]

be the leaf in the wind, Shaz.

Anything pressing on iOS that needs to be resolved? I am aware of a bug in
Camera, which I can take a look at. Anything else you want in?


On Thu, Jun 13, 2013 at 11:01 AM, Shazron  wrote:

> I wish I could say there was more velocity in the iOS / OS X repos but
> there hasn't been any with me being away at WWDC this week, but if that's
> where the wind blows I am but a feather. Will try to get more issues
> resolved by rc2.
>
>
> On Thu, Jun 13, 2013 at 9:27 AM, Lorin Beer  >wrote:
>
> > +1, let's tackle this early
> >
> >
> > On Wed, Jun 12, 2013 at 4:06 PM, Jesse  wrote:
> >
> > > meh
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Wed, Jun 12, 2013 at 4:03 PM, Filip Maj  wrote:
> > >
> > > > Huge +1!
> > > >
> > > > On 6/12/13 3:56 PM, "Joe Bowser"  wrote:
> > > >
> > > > >Hey
> > > > >
> > > > >I know this is pretty soon, but how does a 2.9.0rc1 on Monday sound?
> > > > >Since this is supposed to be a hardening release anyway, I don't see
> > > > >why we shouldn't start with the RCs.
> > > > >
> > > > >Any thoughts?
> > > > >
> > > > >Joe
> > > >
> > > >
> > >
> >
>

Re: 2.9.0rc1 this coming monday??

[Lorin Beer]

+1, let's tackle this early


On Wed, Jun 12, 2013 at 4:06 PM, Jesse  wrote:

> meh
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Jun 12, 2013 at 4:03 PM, Filip Maj  wrote:
>
> > Huge +1!
> >
> > On 6/12/13 3:56 PM, "Joe Bowser"  wrote:
> >
> > >Hey
> > >
> > >I know this is pretty soon, but how does a 2.9.0rc1 on Monday sound?
> > >Since this is supposed to be a hardening release anyway, I don't see
> > >why we shouldn't start with the RCs.
> > >
> > >Any thoughts?
> > >
> > >Joe
> >
> >
>

Re: issues.apache.org is down

[Lorin Beer]

jira is back up, as of a few minutes ago. git-wip still down


On Tue, Jun 11, 2013 at 8:10 AM, Filip Maj  wrote:

> http://monitoring.apache.org/status/
>
>
> Git-wip is down but JIRA is up for me.
>
> On 6/11/13 8:05 AM, "Simon MacDonald"  wrote:
>
> >Looks like:
> >
> >https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=summary
> >
> >Is down for me too.
> >
> >Simon Mac Donald
> >http://hi.im/simonmacdonald
> >
> >
> >On Tue, Jun 11, 2013 at 11:02 AM, Lorin Beer 
> >wrote:
> >> yeah, getting that too.
> >> you can ping issues.apache.org, it looks like just the jira tracker is
> >>down.
> >> Waiting patiently
> >>
> >>
> >> On Tue, Jun 11, 2013 at 8:00 AM, Michael Sierra 
> >>wrote:
> >>
> >>> The subject says it all.
> >>>
> >>> --Mike S
>
>