Draft blog post for transitioning off cordova-plugin-file-transfer

[Filip Maj]

https://github.com/apache/cordova-docs/pull/746

Comments, reviews, questions, ideas, whatever are welcome!

Appreciate any feedback folks have.

Cheers,
Fil

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS][DOCS] Revert a change

[Filip Maj]

To be clear, we don't need to redesign anything to automate docs
deployment. It is in the realm of possibility to simply automate what
we have today. I just feel like what we have today is a design where
translations are an afterthought, which I think is a bad tradeoff,
especially given the popularity of cordova outside of english-speaking
countries. _IF_ we were to agree that a redesign is worthwhile, then I
would recommend we do that first before automating deployment. If the
PMC deems a redesign of the cordova-docs repo is not important, then
so be it, and we can automate what we have.

On Wed, Sep 13, 2017 at 12:09 PM, Dmitry Blotsky
<dmitry.blot...@gmail.com> wrote:
> @fil: why is reworking the docs repo needed for automatic deployment?
>
> @steve: could you merge it then? I'm far too rusty on my Cordova-ing to 
> remember how to set up my remotes to push to the ASF repo, sorry. :(
>
> Kindly,
> Dmitry
>
>> On Sep 13, 2017, at 1:08 PM, Filip Maj <maj@gmail.com> wrote:
>>
>> We have an issue posted to make docs publishing automatic:
>> https://issues.apache.org/jira/browse/CB-13162
>>
>> Not to derail the topic, but there is a longer wishlist in that issue,
>> and I do think achieving the goals in that issue would require
>> reworking the docs repository quite a bit. We can discuss details in
>> the issue thread.
>>
>> On Wed, Sep 13, 2017 at 9:47 AM, Dmitry Blotsky
>> <dmitry.blot...@gmail.com> wrote:
>>> Yes, ideally our deployment process should be automated. Also, it should 
>>> *not* be an SVN commit. It should be an rsync or an scp command. I would 
>>> support any initiatives to move to either one of those. If we had automated 
>>> deployment, this discussion would be moot.
>>>
>>> How much would it cost us to just have a VPS with nginx?
>>>
>>> Switching to the topic of deployment docs now. Thanks, Shaz, for bringing 
>>> this up in discussion. My opinion was that we shouldn't have impactful 
>>> commands be copy-paste-able, which is why I had the instruction to commit 
>>> in paragraph text. I think that if a committer doesn't read the full text 
>>> of the deployment docs, *they should not be deploying*. I can see the 
>>> argument that if they do read the text but just don't know *how* to commit 
>>> in SVN, it's annoying to search. However at the top of that section is an 
>>> explicit link to a quick SVN tutorial. I understand that not everyone reads 
>>> the fine print, but IMO committers should, and we should explicitly 
>>> discourage that behaviour.
>>>
>>> Ultimately I'm going to defer to Shaz here, but I think it's important to 
>>> consider the benefits of making deployment *feel* more serious by making 
>>> RTFD necessary.
>>>
>>> Kindly,
>>> Dmitry
>>>
>>>> On Sep 13, 2017, at 6:30 AM, Jan Piotrowski <piotrow...@gmail.com> wrote:
>>>>
>>>> I am actually surprised deploying is a manual process at all.
>>>> Having read the steps, I understand why of course.
>>>>
>>>> As a person that jumps in on all kinds of projects, I absolutely
>>>> prefer docs that list each and every little step needed (including all
>>>> the `cd` etc).
>>>>
>>>> The need for manual steps or checks could be emphasized by using a
>>>> numbered list or checklist for the individual steps.
>>>>
>>>> (Will this stay on SVN even after the repo switch to Github? Merging
>>>> and `gh-pages` is so nice and simple)
>>>>
>>>> -J
>>>>
>>>> 2017-09-13 9:02 GMT+02:00 Shazron <shaz...@gmail.com>:
>>>>> This relates solely to instructions on how to *build* the site, and not 
>>>>> the
>>>>> contents of the site itself.
>>>>>
>>>>> Bringing this up here for discussion since a committer wants to revert a
>>>>> change by another committer, and there is potential for disagreement.
>>>>>
>>>>> The pull request to revert is here:
>>>>> https://github.com/apache/cordova-docs/pull/729
>>>>>
>>>>> There has been discussion on the original change here:
>>>>> https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94
>>>>>
>>>>> Two issues here:
>>>>> 1. The change from `gulp build --prod` to `npm run serve`
>>>>> 2. This instruction here (not reverted in the PR):
>>>>> https://github.com/apache/

Re: [DISCUSS][DOCS] Revert a change

[Filip Maj]

We have an issue posted to make docs publishing automatic:
https://issues.apache.org/jira/browse/CB-13162

Not to derail the topic, but there is a longer wishlist in that issue,
and I do think achieving the goals in that issue would require
reworking the docs repository quite a bit. We can discuss details in
the issue thread.

On Wed, Sep 13, 2017 at 9:47 AM, Dmitry Blotsky
 wrote:
> Yes, ideally our deployment process should be automated. Also, it should 
> *not* be an SVN commit. It should be an rsync or an scp command. I would 
> support any initiatives to move to either one of those. If we had automated 
> deployment, this discussion would be moot.
>
> How much would it cost us to just have a VPS with nginx?
>
> Switching to the topic of deployment docs now. Thanks, Shaz, for bringing 
> this up in discussion. My opinion was that we shouldn't have impactful 
> commands be copy-paste-able, which is why I had the instruction to commit in 
> paragraph text. I think that if a committer doesn't read the full text of the 
> deployment docs, *they should not be deploying*. I can see the argument that 
> if they do read the text but just don't know *how* to commit in SVN, it's 
> annoying to search. However at the top of that section is an explicit link to 
> a quick SVN tutorial. I understand that not everyone reads the fine print, 
> but IMO committers should, and we should explicitly discourage that behaviour.
>
> Ultimately I'm going to defer to Shaz here, but I think it's important to 
> consider the benefits of making deployment *feel* more serious by making RTFD 
> necessary.
>
> Kindly,
> Dmitry
>
>> On Sep 13, 2017, at 6:30 AM, Jan Piotrowski  wrote:
>>
>> I am actually surprised deploying is a manual process at all.
>> Having read the steps, I understand why of course.
>>
>> As a person that jumps in on all kinds of projects, I absolutely
>> prefer docs that list each and every little step needed (including all
>> the `cd` etc).
>>
>> The need for manual steps or checks could be emphasized by using a
>> numbered list or checklist for the individual steps.
>>
>> (Will this stay on SVN even after the repo switch to Github? Merging
>> and `gh-pages` is so nice and simple)
>>
>> -J
>>
>> 2017-09-13 9:02 GMT+02:00 Shazron :
>>> This relates solely to instructions on how to *build* the site, and not the
>>> contents of the site itself.
>>>
>>> Bringing this up here for discussion since a committer wants to revert a
>>> change by another committer, and there is potential for disagreement.
>>>
>>> The pull request to revert is here:
>>> https://github.com/apache/cordova-docs/pull/729
>>>
>>> There has been discussion on the original change here:
>>> https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94
>>>
>>> Two issues here:
>>> 1. The change from `gulp build --prod` to `npm run serve`
>>> 2. This instruction here (not reverted in the PR):
>>> https://github.com/apache/cordova-docs/commit/d61f3ddc84dac4b013c0607230b9cf10921a416b
>>>
>>> Issue (1) has some discussion in the GH link above for the original change.
>>>
>>> Issue (2) there was some discussion in the Cordova Slack, that the reason
>>> the `svn commit` wasn't there in the first place is to prevent copy/paste
>>> of the commands without going through the changes step by step since
>>> deploying to a site is an expensive operation that can screw up the site if
>>> proper care was not done.
>>>
>>> My reason for adding the command was that the instructions are not complete
>>> (when I had to do it myself when updating the docs for cordova-ios
>>> release). I understand the rationale, but the instructions seem incomplete
>>> (especially for new committers that haven't heard of SVN, I know they can
>>> Google it, but that's more friction) and my other reason is: we should
>>> trust that committers will do the right thing.
>>>
>>> Not to make a mountain out of a mole-hill but it's important that these
>>> revert discussions be out in the open so as misunderstandings/hurt feelings
>>> don't occur, and we can nip it in the bud.
>>>
>>> Thoughts from the community?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] cordova-ios 4.1.1 Release

[Filip Maj]

By the way, I think we should include notes about
cordova-plugin-console being integrated in the blog post /
announcement for this release - that may trip up folks trying to
update cordova-ios, if they had the console plugin manually installed
already.

On Thu, Aug 31, 2017 at 7:21 PM, Shazron <shaz...@gmail.com> wrote:
> Stalled on testing and fixing https://github.com/apache/cordova-ios/pull/335
> before a release can be sent for vote
>
> On Thu, Aug 24, 2017 at 4:12 PM, Shazron <shaz...@gmail.com> wrote:
>
>> Issues on the board have been completed, the PRs need review:
>>
>> Board:
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=173
>>
>> Pull requests:
>> 1. https://github.com/apache/cordova-ios/pull/326
>> 2. https://github.com/apache/cordova-ios/pull/331
>> 3. https://github.com/apache/cordova-ios/pull/332
>>
>>
>> On Tue, Aug 22, 2017 at 6:00 PM, Shazron <shaz...@gmail.com> wrote:
>>
>>> Renamed board to 4.5.0, left Fil's issue and another that has a PR that
>>> is almost done review:
>>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=173
>>>
>>> On Tue, Aug 22, 2017 at 11:47 AM, Shazron <shaz...@gmail.com> wrote:
>>>
>>>> I'll get that in as the lone issue on the board.
>>>> I'm also thinking this should be 4.5.0 instead of 4.4.1 because there is
>>>> a new feature in there.
>>>>
>>>> On Tue, Aug 22, 2017 at 9:20 AM, Filip Maj <maj@gmail.com> wrote:
>>>>
>>>>> CB-12830 [1] is something that I think we should sneak in to the
>>>>> release, time permitting.
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/CB-12830
>>>>>
>>>>> On Sat, Aug 12, 2017 at 4:05 AM, Shazron <shaz...@gmail.com> wrote:
>>>>> >  I do! yes 4.4.1
>>>>> >
>>>>> > On Aug 11, 2017 at 5:40 PM, julio cesar sanchez <
>>>>> jcesarmob...@gmail.com>
>>>>> > wrote:
>>>>> >
>>>>> >
>>>>> > You probably mean 4.4.1
>>>>> >
>>>>> > El 11 ago. 2017 3:37 p. m., "Steven Gill" <stevengil...@gmail.com>
>>>>> escribió:
>>>>> >
>>>>> > Yay!
>>>>> >
>>>>> > On Aug 11, 2017 12:19 PM, "Shazron" <shaz...@gmail.com> wrote:
>>>>> >
>>>>> > Long overdue.
>>>>> >
>>>>> > The board is here:
>>>>> > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=173
>>>>> >
>>>>> > Any issues in the left column that absolutely need to go in? If not I
>>>>> >
>>>>> > will
>>>>> >
>>>>> > punt them to the next release.
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>>>
>>>>>
>>>>
>>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [GITHUB MOVE] Bulk move of all repos

[Filip Maj]

Should we delete/remove/archive any of those before moving them over?
We have repos like app harness, medic, and others that are not
contributed to nor used anymore.

On Tue, Aug 29, 2017 at 10:13 PM, Steven Gill  wrote:
> We can deal with jira issues -> github issues migration once all repos are
> moved over.
>
> On Tue, Aug 29, 2017 at 11:19 AM, Steven Gill 
> wrote:
>
>> do it!
>>
>>
>> On Tue, Aug 29, 2017 at 11:18 AM, Shazron  wrote:
>>
>>> See: https://issues.apache.org/jira/browse/INFRA-14398
>>>
>>> INFRA (through Daniel Gruno) has commented on Hipchat that a bulk move
>>> would be easier for us, versus a selective move.
>>>
>>> Ironically the proposed 3 Phase approach was to make it easier for INFRA
>>> to
>>> transition us.
>>>
>>> Updated proposal:
>>> Move **all** our repos from git-wip-us.apache.org to Github?
>>>
>>> +1 for me.
>>>
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] cordova-ios 4.1.1 Release

[Filip Maj]

CB-12830 [1] is something that I think we should sneak in to the
release, time permitting.

[1] https://issues.apache.org/jira/browse/CB-12830

On Sat, Aug 12, 2017 at 4:05 AM, Shazron  wrote:
>  I do! yes 4.4.1
>
> On Aug 11, 2017 at 5:40 PM, julio cesar sanchez 
> wrote:
>
>
> You probably mean 4.4.1
>
> El 11 ago. 2017 3:37 p. m., "Steven Gill"  escribió:
>
> Yay!
>
> On Aug 11, 2017 12:19 PM, "Shazron"  wrote:
>
> Long overdue.
>
> The board is here:
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=173
>
> Any issues in the left column that absolutely need to go in? If not I
>
> will
>
> punt them to the next release.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [GitHub] shazron closed pull request #329: CB-13112 - should not create a new file reference on each "cordova prepare"

[Filip Maj]

Well, it's a PR-specific one (open/close PR actions send an email). We
asked for commits to not be sent to dev, not for PR activity to not be
sent to dev.

On Thu, Aug 10, 2017 at 1:48 PM, Steven Gill  wrote:
> This email shouldn't be coming to the mailing list right?
>
> On Thu, Aug 10, 2017 at 1:26 PM,  wrote:
>
>> shazron closed pull request #329: CB-13112 -  should not
>> create a new file reference on each "cordova prepare"
>> URL: https://github.com/apache/cordova-ios/pull/329
>>
>>
>>
>>
>> 
>> This is an automated message from the Apache Git Service.
>> To respond to the message, please log on GitHub and use the
>> URL above to go to the specific comment.
>>
>> For queries about this service, please contact Infrastructure at:
>> us...@infra.apache.org
>>
>>
>> With regards,
>> Apache Git Services
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: git commits being sent to dev

[Filip Maj]

Looks like it's no longer spamming. HooraY!

On Wed, Aug 9, 2017 at 10:44 AM, Steven Gill  wrote:
> it should be changed to comm...@cordova.apache.org now. Lets see
>
> On Tue, Aug 8, 2017 at 4:01 PM, Steven Gill  wrote:
>
>> https://issues.apache.org/jira/browse/INFRA-14823
>>
>> On Tue, Aug 8, 2017 at 3:41 PM, Shazron  wrote:
>>
>>> Yeah, the last time was through JIRA -> Service Desk tab -> Create Service
>>> Desk Request -> Apache Infrastructure -> Github Integration
>>>
>>> On Tue, Aug 8, 2017 at 3:26 PM, Steven Gill 
>>> wrote:
>>>
>>> > How do we get them to change it? File an issue with infra I guess?
>>> >
>>> > On Tue, Aug 8, 2017 at 11:18 AM, Shazron  wrote:
>>> >
>>> > > They shouldn't be going to dev@, instead they should be going to
>>> > commits@
>>> > >
>>> > > On Tue, Aug 8, 2017 at 11:10 AM, Simon MacDonald <
>>> > > simon.macdon...@gmail.com>
>>> > > wrote:
>>> > >
>>> > > > I agree, don't send commit's do the dev list.
>>> > > >
>>> > > > Simon Mac Donald
>>> > > > http://simonmacdonald.com
>>> > > >
>>> > > > On Tue, Aug 8, 2017 at 1:54 PM, Joe Bowser 
>>> wrote:
>>> > > >
>>> > > > > I'm already filtering all that stuff since I'm already getting it.
>>> > In
>>> > > > > fact, this is why I didn't see the Github invite.
>>> > > > >
>>> > > > > But yeah, we should not have the commit e-mails go to the dev
>>> mailing
>>> > > > list,
>>> > > > > since it'll just spam everyone.  It'd be good if more people would
>>> > use
>>> > > > the
>>> > > > > list to talk about proposals, or at least link to the proposal on
>>> > > GitHub,
>>> > > > > since it's not the Apache way to do stuff outside of the mailing
>>> > list.
>>> > > > >
>>> > > > > (Yeah, I'm being serious about the mailing list and the Apache
>>> way.
>>> > We
>>> > > > > should use the dev list for discussion more.)
>>> > > > >
>>> > > > > On Tue, Aug 8, 2017 at 10:39 AM, Steven Gill <
>>> stevengil...@gmail.com
>>> > >
>>> > > > > wrote:
>>> > > > >
>>> > > > > > Hey!
>>> > > > > >
>>> > > > > > How do people feel about these git commit emails being sent to
>>> dev
>>> > > > > mailing
>>> > > > > > list. This is only happening to repos that have fully switched
>>> over
>>> > > to
>>> > > > > > github (gitbox setup).
>>> > > > > >
>>> > > > > > Personally, I am already watching the repos so I get the
>>> emails. I
>>> > > > don't
>>> > > > > > need the emails to come to dev. I think it would be better
>>> people
>>> > > just
>>> > > > > > click watch on repos they want emails from, setup mail filters
>>> and
>>> > go
>>> > > > > from
>>> > > > > > there. No need for commit emails to be sent to dev.
>>> > > > > >
>>> > > > > > I could just as easily update my mail filters to move the git
>>> > emails
>>> > > > > being
>>> > > > > > sent to dev into a different directory.
>>> > > > > >
>>> > > > > > Thoughts?
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [CORE PLUGINS][DISCUSS] Roadmap 2017

[Filip Maj]

There is a clear path forward for most plugins. The plugins-next board
has ~60 issues to tackle to sunset, integrate and update 'em all. Lots
of work to do, but it should be healthy for the project.

One thing I wanted to point out is that the decision on the Dialogs
plugin has been waffling (full discussion in the issue [1]).
Initially, we had voted to keep + update to polyfill the HTML 
element. Turns out there is a Google-written polyfill out there
already [2]. Simon and I think we should switch the decision on this
plugin to "SUNSET", that is, announce that we will no longer be
maintaining the plugin, let the community take it over if they wish,
and toss up a blog post detailing how to transition to the 
element / leverage the polyfill if necessary.

If you have opinions on this, please chime in on the thread. On Monday
I'll move forward with formalizing the decision/tasks in there.

[1] https://issues.apache.org/jira/browse/CB-12719
[2] https://github.com/GoogleChrome/dialog-polyfill

On Fri, Jul 28, 2017 at 12:57 PM, Filip Maj <maj@gmail.com> wrote:
> Small update on this topic:
>
>  - still need to clarify next steps on some of the INTEGRATE plugins
>  - I think the Dialogs plugin's KEEP + UPDATE decision needs a bit of
> clarification as well
>  - I am trying to work with the W3C's web platform tests [1] to
> validate latest spec adherance on the Android and iOS OS versions that
> cordova-android and cordova-ios currently support. For now looking at
> APIs such as the File API and XHR. The reason I am doing this is to
> understand _what_ APIs we still need to polyfill for these
> platforms+versions. Ideally, a lot of these APIs are built in and
> passing the tests, so moving forward we only have to implement the
> minimum set of APIs where support is still wobbly inside cordova. I
> will be reporting these results in the relevant issues per API.
>
> For those wanting to get the w3c-platform-tests working with cordova,
> I got it working by changing the `host` property in the
> config.default.json file to a local-network IP (e.g. 192.168.xxx.xxx,
> which I use to access the tests from my device), and creating a new
> cordova app that whitelists that IP (on port 8000), and pointing the
>  location to that IP + port.
>
> [1] https://github.com/w3c/web-platform-tests
>
> On Tue, Jul 25, 2017 at 9:59 AM, Kerri Shotts <kerrisho...@gmail.com> wrote:
>> Just wanted to say “THANKS!” for the work you’ve done on this! :-) It’s much 
>> appreciated!
>>
>> ~ Kerri
>>
>>> On Jul 22, 2017, at 14:43, Filip Maj <maj@gmail.com> wrote:
>>> ...
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Moving JIRA issues to Github

[Filip Maj]

Did a little searching, and GitHub has a global issue search you can
use: https://github.com/issues

Combine that with a custom search query, essentially a giant chain of
(repo:apache/cordova-browser or repo:apache/cordova-android) etc., and
I think you could get what you want.

On Thu, Aug 3, 2017 at 4:30 AM, Jan Piotrowski <piotrow...@gmail.com> wrote:
>> What about security issues?
>> Right now on jira we have private security issues not visible for the 
>> regular people and as far as I know, we can't do that on GitHub
>
> Initial idea: Have an email address where people can send messages to,
> the recipient then creates an issue on a private Github repo for
> further talking about it.
> You could probably also create a public form that does the same job of
> the email address and person creating the ticket automatically if too
> much effort and needed too often.
> (But maybe there is a better solution, one could investigate how other
> Github based projects do that)
>
> -J
>
> 2017-08-03 11:55 GMT+02:00 julio cesar sanchez <jcesarmob...@gmail.com>:
>> What about security issues?
>>
>> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <piotrow...@gmail.com> escribió:
>>
>>> >> As a user, I’ll occasionally skim the recently opened bugs in Jira
>>> across the entire project to see if any may affect us. Is there going to be
>>> a way to do this with Github? Subscribing to notifications could be a
>>> work-around but it’s not ideal.
>>> >
>>> > Good question. I can't really think of a way to do this...
>>>
>>> Github doesn't offer this out of the box (besides watching all repos
>>> yourself, which comes with its own challenges). But Github has an API,
>>> I am pretty sure someone already wrote something that combines issues
>>> of several repos into one interface to look at, then links to the
>>> individual issues (If not, it wouldn't be too much work to create
>>> something like that) (Could become the new issues.cordova.io maybe?).
>>> Would this fulfill your use case?
>>>
>>> -J
>>>
>>> 2017-08-03 3:13 GMT+02:00 Filip Maj <maj@gmail.com>:
>>> >> Since it looks like not all repositories will be migrated where should
>>> their issues go?
>>> >
>>> > All repositories will be migrated.
>>> >
>>> >> What about issues for repositories that don’t yet exist
>>> >
>>> > Can you give me an example?
>>> >
>>> >> or cross-cutting issues?
>>> >
>>> > I think if you absolutely need issues related to multiple repos, you
>>> > can always create multiple issues in all relevant repos and
>>> > cross-reference them.
>>> >
>>> >> As a user, I’ll occasionally skim the recently opened bugs in Jira
>>> across the entire project to see if any may affect us. Is there going to be
>>> a way to do this with Github? Subscribing to notifications could be a
>>> work-around but it’s not ideal.
>>> >
>>> > Good question. I can't really think of a way to do this...
>>> >
>>> >> Are we going to get more high quality bug reports using Github? This
>>> may not be answerable without trying it out, but making issues easier to
>>> create issues could cause an influx of questions and non-cordova related
>>> bugs. This could add on to the difficulties of triaging and migrating bugs
>>> across repos.
>>> >
>>> > To be fair, we already get painful triage-work via GitHub just by
>>> > opening up Pull Requests to the public. People will use those to post
>>> > questions or issues, because they are unaware that there are other
>>> > support and issue filing avenues (they will mask them as PRs merging a
>>> > release branch into master). At least those people now have a more
>>> > obvious place to file issues: the Issues section on GitHub. We already
>>> > have a lot of triage work on JIRA as it is. I doubt this will go down.
>>> > That said, I don't think that's necessarily bad. Will we have more
>>> > work? Probably. Will we be able to more easily identify issues, and
>>> > earlier, and generally be also more accessible to our community? I
>>> > would think yes. Double-edged sword. I say let's see how it goes.
>>> >
>>> >> If we migrate before triaging where will all the un-triaged issues end
>>> up?
>>> >
>>> > They would end up in GitHub, at which point

Re: [DISCUSS] Moving JIRA issues to Github

[Filip Maj]

> The one I was thinking of was cordova-plugins. Do we want some way to track
> issues for inactive platforms too or should those be considered permanently
> closed?

Possibly. I think we will still have JIRA around w/ deprecated
components, maybe? I'm not sure. Shaz?

> For example a new platform or core plugin is created. I'd assume we could
> create an empty repository, but I'm not sure what the overhead of
> requesting a new repo is. Experimental plugins or research might fall into
> this category as well. I guess the more general question is are there any
> Jira tasks we use that aren't tied to a repo and if so where should track
> them in Github?

To create new repos, we will have to go through Infra anyways.
Experimental code in cordova has gone into branches in the
cordova-labs repo in the past.

> Is there going to be a default repository to hold them before they're
> triaged and organized?

Oh I think I see what you mean now. As in, what do we do with JIRA
issues without an assigned component that does maps to one of the new
GH repos, what do we do with those? That's a good question. Perhaps
that points to us doing a big JIRA issue cleanup before we undergo a
migration. FWIW I did a couple weeks back already and am fairly
confident most relevant issues have an assigned component.

On Wed, Aug 2, 2017 at 6:51 PM, Connor Pearson <cjp...@gmail.com> wrote:
>>> Since it looks like not all repositories will be migrated where should
> their issues go?
>> All repositories will be migrated.
>
> The one I was thinking of was cordova-plugins. Do we want some way to track
> issues for inactive platforms too or should those be considered permanently
> closed?
>
>>> What about issues for repositories that don’t yet exist
>> Can you give me an example?
>
> For example a new platform or core plugin is created. I'd assume we could
> create an empty repository, but I'm not sure what the overhead of
> requesting a new repo is. Experimental plugins or research might fall into
> this category as well. I guess the more general question is are there any
> Jira tasks we use that aren't tied to a repo and if so where should track
> them in Github?
>
>>> If we migrate before triaging where will all the un-triaged issues end
> up?
>> They would end up in GitHub, at which point we'd triage them within
> GitHub.
>
> Is there going to be a default repository to hold them before they're
> triaged and organized?
>
> On a slightly different note, I'm looking forward to the new PR process. It
> always felt a little strange in the past.
>
>
>
> On Wed, Aug 2, 2017 at 9:13 PM, Filip Maj <maj@gmail.com> wrote:
>
>> > Since it looks like not all repositories will be migrated where should
>> their issues go?
>>
>> All repositories will be migrated.
>>
>> > What about issues for repositories that don’t yet exist
>>
>> Can you give me an example?
>>
>> > or cross-cutting issues?
>>
>> I think if you absolutely need issues related to multiple repos, you
>> can always create multiple issues in all relevant repos and
>> cross-reference them.
>>
>> > As a user, I’ll occasionally skim the recently opened bugs in Jira
>> across the entire project to see if any may affect us. Is there going to be
>> a way to do this with Github? Subscribing to notifications could be a
>> work-around but it’s not ideal.
>>
>> Good question. I can't really think of a way to do this...
>>
>> > Are we going to get more high quality bug reports using Github? This may
>> not be answerable without trying it out, but making issues easier to create
>> issues could cause an influx of questions and non-cordova related bugs.
>> This could add on to the difficulties of triaging and migrating bugs across
>> repos.
>>
>> To be fair, we already get painful triage-work via GitHub just by
>> opening up Pull Requests to the public. People will use those to post
>> questions or issues, because they are unaware that there are other
>> support and issue filing avenues (they will mask them as PRs merging a
>> release branch into master). At least those people now have a more
>> obvious place to file issues: the Issues section on GitHub. We already
>> have a lot of triage work on JIRA as it is. I doubt this will go down.
>> That said, I don't think that's necessarily bad. Will we have more
>> work? Probably. Will we be able to more easily identify issues, and
>> earlier, and generally be also more accessible to our community? I
>> would think yes. Double-edged sword. I say let's see how it goes.
>>
>> > If we migrate before triaging where will all th

Re: cordova 8 proposal

[Filip Maj]

Thanks for kicking this off. Lotsa good stuff in there, but lots to
sort through. Recommend everyone take a look!

On Wed, Aug 2, 2017 at 4:51 PM, Steven Gill  wrote:
> Let me know what you think!
> https://github.com/cordova/cordova-discuss/pull/72

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [GITHUB MOVE] Phase 1 Complete, next steps

[Filip Maj]

at some point should we migrate / create a cordova-discuss repo [1] to
the apache org?

[1] https://github.com/cordova/cordova-discuss

On Wed, Aug 2, 2017 at 12:42 PM, Shazron  wrote:
> Phase 1 complete:
> https://issues.apache.org/jira/browse/INFRA-14347
>
> We need to:
>
> 1. Update some of our tools, mainly Coho, to point directly to Github,
> since the git-wip-us.a.o repo is now gone.
> 2. Update our docs
> 3. Update our website (contribution)
>
> I think we need to do 2. and 3. once Phases 2 and 3 are done as well.
> We can do gradual updates of 1. as repos are migrated (should just be a
> json file).
>
> The Git repo now exists on Apache at:
> https://gitbox.apache.org/repos/asf?p=REPO-NAME.git
>
> .. but we will primarily push to Github.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Moving JIRA issues to Github

[Filip Maj]

> Since it looks like not all repositories will be migrated where should their 
> issues go?

All repositories will be migrated.

> What about issues for repositories that don’t yet exist

Can you give me an example?

> or cross-cutting issues?

I think if you absolutely need issues related to multiple repos, you
can always create multiple issues in all relevant repos and
cross-reference them.

> As a user, I’ll occasionally skim the recently opened bugs in Jira across the 
> entire project to see if any may affect us. Is there going to be a way to do 
> this with Github? Subscribing to notifications could be a work-around but 
> it’s not ideal.

Good question. I can't really think of a way to do this...

> Are we going to get more high quality bug reports using Github? This may not 
> be answerable without trying it out, but making issues easier to create 
> issues could cause an influx of questions and non-cordova related bugs. This 
> could add on to the difficulties of triaging and migrating bugs across repos.

To be fair, we already get painful triage-work via GitHub just by
opening up Pull Requests to the public. People will use those to post
questions or issues, because they are unaware that there are other
support and issue filing avenues (they will mask them as PRs merging a
release branch into master). At least those people now have a more
obvious place to file issues: the Issues section on GitHub. We already
have a lot of triage work on JIRA as it is. I doubt this will go down.
That said, I don't think that's necessarily bad. Will we have more
work? Probably. Will we be able to more easily identify issues, and
earlier, and generally be also more accessible to our community? I
would think yes. Double-edged sword. I say let's see how it goes.

> If we migrate before triaging where will all the un-triaged issues end up?

They would end up in GitHub, at which point we'd triage them within GitHub.

> Also if we enable Github issues before phase 2 are we going to be using both 
> Jira and Github Issues for a period of time?

Yes.

Different topic: Shaz, based on your INFRA ticket / phase breakdown,
the implication is that there will be leftover cordova repos in Apache
Git (cordova-medic, weinre, deprecated platforms / plugins). What do
we do with those? Separate discussion?

On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson <cjp...@gmail.com> wrote:
> I have a few questions about moving issues to GitHub. I haven’t used Github
> issues much so these all may be easily solvable.
>
> * Since it looks like not all repositories will be migrated where should
> their issues go? What about issues for repositories that don’t yet exist or
> cross-cutting issues?
> * As a user, I’ll occasionally skim the recently opened bugs in Jira across
> the entire project to see if any may affect us. Is there going to be a way
> to do this with Github? Subscribing to notifications could be a work-around
> but it’s not ideal.
> * Are we going to get more high quality bug reports using Github? This may
> not be answerable without trying it out, but making issues easier to create
> issues could cause an influx of questions and non-cordova related bugs.
> This could add on to the difficulties of triaging and migrating bugs across
> repos.
> * If we migrate before triaging where will all the un-triaged issues end
> up? Also if we enable Github issues before phase 2 are we going to be using
> both Jira and Github Issues for a period of time?
>
> -Connor
>
>
> On August 2, 2017 at 7:08:18 PM, Jan Piotrowski (piotrow...@gmail.com)
> wrote:
>
> If people post their issue at the wrong repo (which of course can and
> will happen from time to time), there is a way to move them over with
> minimal loss of information:
>
> https://github.com/ionic-team/ionic/issues/12542
> https://github.com/ionic-team/ionic-cli/issues/2597
>
> This works for issues where several people replied already in the
> exact same way:
>
> https://github.com/ionic-team/ionic/issues/11898
> https://github.com/ionic-team/ionic-cli/issues/2386
>
> As the original poster of the issue and each reply is @-mentioned they
> are notified about the "new" issue and can continue participating.
> Replying users also can just include the @username in their new
> replies again to make sure people get notified.
>
> -J
>
>
>
> 2017-08-02 21:53 GMT+02:00 Filip Maj <maj@gmail.com>:
>> I think the ease of use of GitHub issues overcomes potential problems
>> about cross-referencing issues. Worth noting on this topic that GitHub
>> already provides good support for referencing pull requests from
>> issues across repos / orgs.
>>
>> The benefit of having issues and PRs in one place, to me, is a benefit
>> too tasty to pass up.

Re: [DISCUSS] Moving JIRA issues to Github

[Filip Maj]

I think the ease of use of GitHub issues overcomes potential problems
about cross-referencing issues. Worth noting on this topic that GitHub
already provides good support for referencing pull requests from
issues across repos / orgs.

The benefit of having issues and PRs in one place, to me, is a benefit
too tasty to pass up.

Darryl, do you have examples of issues that you think could be
problematic in a GitHub-based world?

On Wed, Aug 2, 2017 at 12:43 PM, Darryl Pogue  wrote:
> My concern with GitHub issues is that we have a tonne of repos and issues
> can easily span across them, and we'd lose the one central place for issue
> tracking and triage. I worry that we'd be inundated with issues on the
> wrong repos, or without additional information, and triaging would become
> an insurmountable chore leading to a worse backlog than we already have in
> JIRA.
>
> On 2 August 2017 at 12:38, Shazron  wrote:
>
>> Phase 1 of our move to Github is complete, see:
>> https://issues.apache.org/jira/browse/INFRA-14347
>>
>> We need a migration plan for moving JIRA issues to Github Issues before we
>> enable Github Issues on those repos.
>>
>> Once we figure those out, we can proceed with Phase 2:
>> https://issues.apache.org/jira/browse/INFRA-14398
>>
>> I'll start it off by saying that ideally we:
>> 1. Triage issues
>> 2. Automate migration of existing open issues to Github issues
>> 3. "Close off" the JIRA issues
>>
>> The impact of this is, the original reporters will not get notified of
>> further updates to the issue except for a link to the new issue on Github
>> as a JIRA comment (since they will not be subscribed to the Github issue).
>>
>> We could also migrate every open issue first, then triage later in Github,
>> as well.
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [GITHUB MOVE] Phase 1 Complete, next steps

[Filip Maj]

This makes me so happy :)

On Wed, Aug 2, 2017 at 12:42 PM, Shazron  wrote:
> Phase 1 complete:
> https://issues.apache.org/jira/browse/INFRA-14347
>
> We need to:
>
> 1. Update some of our tools, mainly Coho, to point directly to Github,
> since the git-wip-us.a.o repo is now gone.
> 2. Update our docs
> 3. Update our website (contribution)
>
> I think we need to do 2. and 3. once Phases 2 and 3 are done as well.
> We can do gradual updates of 1. as repos are migrated (should just be a
> json file).
>
> The Git repo now exists on Apache at:
> https://gitbox.apache.org/repos/asf?p=REPO-NAME.git
>
> .. but we will primarily push to Github.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [CORE PLUGINS][DISCUSS] Roadmap 2017

[Filip Maj]

Small update on this topic:

 - still need to clarify next steps on some of the INTEGRATE plugins
 - I think the Dialogs plugin's KEEP + UPDATE decision needs a bit of
clarification as well
 - I am trying to work with the W3C's web platform tests [1] to
validate latest spec adherance on the Android and iOS OS versions that
cordova-android and cordova-ios currently support. For now looking at
APIs such as the File API and XHR. The reason I am doing this is to
understand _what_ APIs we still need to polyfill for these
platforms+versions. Ideally, a lot of these APIs are built in and
passing the tests, so moving forward we only have to implement the
minimum set of APIs where support is still wobbly inside cordova. I
will be reporting these results in the relevant issues per API.

For those wanting to get the w3c-platform-tests working with cordova,
I got it working by changing the `host` property in the
config.default.json file to a local-network IP (e.g. 192.168.xxx.xxx,
which I use to access the tests from my device), and creating a new
cordova app that whitelists that IP (on port 8000), and pointing the
 location to that IP + port.

[1] https://github.com/w3c/web-platform-tests

On Tue, Jul 25, 2017 at 9:59 AM, Kerri Shotts <kerrisho...@gmail.com> wrote:
> Just wanted to say “THANKS!” for the work you’ve done on this! :-) It’s much 
> appreciated!
>
> ~ Kerri
>
>> On Jul 22, 2017, at 14:43, Filip Maj <maj@gmail.com> wrote:
>> ...
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Accepting new apps into the App Showcase

[Filip Maj]

https://issues.apache.org/jira/browse/CB-13126

On Thu, Jul 27, 2017 at 1:52 PM, Steven Gill <stevengil...@gmail.com> wrote:
> File it!
>
> On Thu, Jul 27, 2017 at 1:42 PM, Filip Maj <maj@gmail.com> wrote:
>
>> Is that concensus? Time to file an issue? I love :knife:'ing code
>>
>> On Tue, Jul 25, 2017 at 11:21 PM, Tommy Williams <to...@devgeeks.org>
>> wrote:
>> > +1 to drop it
>> >
>> > On Wed, Jul 26, 2017 at 10:01 AM, Simon MacDonald <
>> simon.macdon...@gmail.com
>> >> wrote:
>> >
>> >> +1 to drop it.
>> >>
>> >> Simon Mac Donald
>> >> http://simonmacdonald.com
>> >>
>> >> On Tue, Jul 25, 2017 at 7:00 PM, Shazron <shaz...@gmail.com> wrote:
>> >>
>> >> > +1 drop it altogether.
>> >> > We can't be the arbiter of what's good or bad, and of course we don't
>> >> have
>> >> > the time nor desire to do so IMO.
>> >> >
>> >> > On Tue, Jul 25, 2017 at 2:32 PM, Steven Gill <stevengil...@gmail.com>
>> >> > wrote:
>> >> >
>> >> > > +1000 I was strongly against having an app showcase when it was
>> >> proposed
>> >> > > for the new site. Nobody ever wants to maintain it.
>> >> > >
>> >> > > On Tue, Jul 25, 2017 at 2:08 PM, Jesse <purplecabb...@gmail.com>
>> >> wrote:
>> >> > >
>> >> > > > +1 to dropping it from cordova
>> >> > > > Let's just link to phonegap-showcase, onsenui-showcase and
>> >> > ionic-showcase
>> >> > > > pages ... I think we should focus on being the best engine and let
>> >> the
>> >> > > > downstreams do the marketing.
>> >> > > >
>> >> > > >
>> >> > > > @purplecabbage
>> >> > > > risingj.com
>> >> > > >
>> >> > > > On Tue, Jul 25, 2017 at 12:43 PM, julio cesar sanchez <
>> >> > > > jcesarmob...@gmail.com> wrote:
>> >> > > >
>> >> > > > > I liked Kerri's idea about only posting open source apps. I
>> think
>> >> > users
>> >> > > > can
>> >> > > > > benefit of it.
>> >> > > > >
>> >> > > > > El 25 jul. 2017 7:52 p. m., "Joe Bowser" <bows...@gmail.com>
>> >> > escribió:
>> >> > > > >
>> >> > > > > > +1 to no longer supporting the Apps section.  Downstream
>> projects
>> >> > get
>> >> > > > > more
>> >> > > > > > benefit from this than we do, IMO.
>> >> > > > > >
>> >> > > > > > On Tue, Jul 25, 2017 at 10:36 AM, Filip Maj <
>> maj@gmail.com>
>> >> > > wrote:
>> >> > > > > >
>> >> > > > > > > I'm of the opinion that we, the cordova devs are already
>> >> sinking
>> >> > > > under
>> >> > > > > > > the amount of incoming PRs and TODOs just with maintaining
>> the
>> >> > > > > > > tooling, platforms, plugins, and docs.
>> >> > > > > > >
>> >> > > > > > > I think it would be better to turf it and let downstream
>> >> projects
>> >> > > do
>> >> > > > > > > that stuff if they wish. I think PhoneGap has one, so does
>> >> ionic.
>> >> > > > > > >
>> >> > > > > > > On Tue, Jul 25, 2017 at 9:58 AM, Kerri Shotts <
>> >> > > kerrisho...@gmail.com
>> >> > > > >
>> >> > > > > > > wrote:
>> >> > > > > > > > If we’re going to have an apps section on the website, it
>> >> would
>> >> > > be
>> >> > > > > good
>> >> > > > > > > to keep it updated. For example, the ReactEurope app goes
>> to a
>> >> > 404
>> >> > > > > page.
>> >> > > > > > > Buildr navigates to an iTunes page that is not available in
>> the
>> >> > US
>> >> > > > > > region,
>> >

Re: [DISCUSS] Accepting new apps into the App Showcase

[Filip Maj]

Is that concensus? Time to file an issue? I love :knife:'ing code

On Tue, Jul 25, 2017 at 11:21 PM, Tommy Williams <to...@devgeeks.org> wrote:
> +1 to drop it
>
> On Wed, Jul 26, 2017 at 10:01 AM, Simon MacDonald <simon.macdon...@gmail.com
>> wrote:
>
>> +1 to drop it.
>>
>> Simon Mac Donald
>> http://simonmacdonald.com
>>
>> On Tue, Jul 25, 2017 at 7:00 PM, Shazron <shaz...@gmail.com> wrote:
>>
>> > +1 drop it altogether.
>> > We can't be the arbiter of what's good or bad, and of course we don't
>> have
>> > the time nor desire to do so IMO.
>> >
>> > On Tue, Jul 25, 2017 at 2:32 PM, Steven Gill <stevengil...@gmail.com>
>> > wrote:
>> >
>> > > +1000 I was strongly against having an app showcase when it was
>> proposed
>> > > for the new site. Nobody ever wants to maintain it.
>> > >
>> > > On Tue, Jul 25, 2017 at 2:08 PM, Jesse <purplecabb...@gmail.com>
>> wrote:
>> > >
>> > > > +1 to dropping it from cordova
>> > > > Let's just link to phonegap-showcase, onsenui-showcase and
>> > ionic-showcase
>> > > > pages ... I think we should focus on being the best engine and let
>> the
>> > > > downstreams do the marketing.
>> > > >
>> > > >
>> > > > @purplecabbage
>> > > > risingj.com
>> > > >
>> > > > On Tue, Jul 25, 2017 at 12:43 PM, julio cesar sanchez <
>> > > > jcesarmob...@gmail.com> wrote:
>> > > >
>> > > > > I liked Kerri's idea about only posting open source apps. I think
>> > users
>> > > > can
>> > > > > benefit of it.
>> > > > >
>> > > > > El 25 jul. 2017 7:52 p. m., "Joe Bowser" <bows...@gmail.com>
>> > escribió:
>> > > > >
>> > > > > > +1 to no longer supporting the Apps section.  Downstream projects
>> > get
>> > > > > more
>> > > > > > benefit from this than we do, IMO.
>> > > > > >
>> > > > > > On Tue, Jul 25, 2017 at 10:36 AM, Filip Maj <maj@gmail.com>
>> > > wrote:
>> > > > > >
>> > > > > > > I'm of the opinion that we, the cordova devs are already
>> sinking
>> > > > under
>> > > > > > > the amount of incoming PRs and TODOs just with maintaining the
>> > > > > > > tooling, platforms, plugins, and docs.
>> > > > > > >
>> > > > > > > I think it would be better to turf it and let downstream
>> projects
>> > > do
>> > > > > > > that stuff if they wish. I think PhoneGap has one, so does
>> ionic.
>> > > > > > >
>> > > > > > > On Tue, Jul 25, 2017 at 9:58 AM, Kerri Shotts <
>> > > kerrisho...@gmail.com
>> > > > >
>> > > > > > > wrote:
>> > > > > > > > If we’re going to have an apps section on the website, it
>> would
>> > > be
>> > > > > good
>> > > > > > > to keep it updated. For example, the ReactEurope app goes to a
>> > 404
>> > > > > page.
>> > > > > > > Buildr navigates to an iTunes page that is not available in the
>> > US
>> > > > > > region,
>> > > > > > > so doesn’t tell me anything (would be better to link to a
>> website
>> > > > > > instead).
>> > > > > > > >
>> > > > > > > > Personally, it might be better just to drop the section
>> > entirely,
>> > > > > since
>> > > > > > > it will require maintenance, would end up with some subjective
>> > > > criteria
>> > > > > > > (leading to “why them and not us?”), and would need to be
>> rotated
>> > > as
>> > > > > new
>> > > > > > > apps are added to prevent a huge list of apps on the front
>> page.
>> > I
>> > > > like
>> > > > > > the
>> > > > > > > idea, but maybe it would be better to have a Cordova App
>> gallery
>> > > > (akin
>> > > > > to
>> > > > > > > Plugin search, cocoapods, etc

Re: WebRTC (getUserMedia) in cordova-ios on iOS11

[Filip Maj]

IIRC, it's not uncommon for the webview to lag behind Mobile Safari.

On Wed, Jul 26, 2017 at 11:47 PM, Toplak Daniel  wrote:
> He devs,
>
> Does anyone played with WebRTC on iOS?
>
> I get a test running only in Safari with iOS 11 Beta 4, but not in a cordova 
> app.
> Both WKWebView and UIWebView seems to have no support of WebRTC.
>
> I did not find any official thing from apple, besides what'*s new in Safari 
> 11: 
> https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Safari_11_0/Safari_11_0.html
> They announce the WebRTC support.
>
> Grüße / Regards
> Daniel Toplak
> Head of Mobile Development
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Incompatible plugin should reject the build

[Filip Maj]

OMG late to this thread but yes, this should fail and freakout. My
assumption is the same as the person who reported CB-12122 is: any
dependent plugins that fail constraint checking would bubble the
failure up the dependency chain. Unfortunately, the behaviour is not
_super_ explicit in the docs [1] - we should fix that. Currently it is
"The CLI aborts with a non-zero code for any plugin whose target
project does not meet the engine's constraints." To me that implies
fail+freakout, but we could elaborate on the wording here a bit more.

This issue is closely entangled with how to integrate certain plugins
into platform code, esp. if the plugin is a common dependency. In
particular looking at cordova-plugin-compat [2]. The decision in this
thread would determine whether future versions of core plugins that
currently depend on compat (camera, geo, and others) would need to
depend on compat forever, or could remove the dependency altogether.
If we keep current behaviour, future versions of e.g. camera need to
keep a  on compat. If we change the behaviour to fail and
freak out, we can remove the dependency after integrating compat into
cordova-android. Strict engine constraints would need to land in
plugins moving forward in either case.

I would also like to push for aligning cordovaDependency and 
behaviour ASAP. As per our docs today [3], we already say "[the
cordovaDependencies] feature is intended to eventually replace the
engines element in plugin.xml." Do we have an issue filed to do that?

[1] 
https://cordova.apache.org/docs/en/latest/plugin_ref/spec.html#engines-and-engine
[2] https://issues.apache.org/jira/browse/CB-12730
[3] 
https://cordova.apache.org/docs/en/latest/guide/hybrid/plugins/index.html#specifying-cordova-dependencies

On Fri, Jun 2, 2017 at 12:15 PM, Kerri Shotts  wrote:
> +1 Fail (I think principle of least surprise applies here; most devs would 
> expect an incompatible plugin to fail the build.)
>
> ~ Kerri
>
>> On Jun 2, 2017, at 12:15, Shazron  wrote:
>>
>> Consensus on this long stewing issue of 7 months?
>>
>> If you deleted the thread:
>> 1. Issue https://issues.apache.org/jira/browse/CB-12122
>> 2. Thread https://s.apache.org/ofqR
>>
>> +1 on engine check failing the build.
>> Questions that need answered: Does cordova-fetch on cordova@7 do this
>> already, like Simon said?
>>
>>
>> On Mon, Nov 7, 2016 at 6:34 PM, Simon MacDonald 
>> wrote:
>>
>>> I think an engine check should fail the build. If there plugin version
>>> they are trying to use will not work with the version of cordova or
>>> platform they are currently using in their project it should not
>>> build. Folks can screw up their semver in config.xml and end up
>>> pulling in a plugin version that doesn't work with the CLI they are
>>> currently using so stuff will just be horribly broken without them
>>> knowing.
>>>
>>> Also, I thought the new cordova-fetch was supposed to prevent this
>>> sort of thing?
>>> Simon Mac Donald
>>> http://simonmacdonald.com
>>>
>>>
>>> On Mon, Nov 7, 2016 at 8:24 PM, Shazron  wrote:
 See https://issues.apache.org/jira/browse/CB-12122

 Right now if a plugin fails an  check, it just warns. Should we
 make engine checks fail the build?
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Accepting new apps into the App Showcase

[Filip Maj]

I'm of the opinion that we, the cordova devs are already sinking under
the amount of incoming PRs and TODOs just with maintaining the
tooling, platforms, plugins, and docs.

I think it would be better to turf it and let downstream projects do
that stuff if they wish. I think PhoneGap has one, so does ionic.

On Tue, Jul 25, 2017 at 9:58 AM, Kerri Shotts  wrote:
> If we’re going to have an apps section on the website, it would be good to 
> keep it updated. For example, the ReactEurope app goes to a 404 page. Buildr 
> navigates to an iTunes page that is not available in the US region, so 
> doesn’t tell me anything (would be better to link to a website instead).
>
> Personally, it might be better just to drop the section entirely, since it 
> will require maintenance, would end up with some subjective criteria (leading 
> to “why them and not us?”), and would need to be rotated as new apps are 
> added to prevent a huge list of apps on the front page. I like the idea, but 
> maybe it would be better to have a Cordova App gallery (akin to Plugin 
> search, cocoapods, etc.)… but that could easily be done by the community, 
> since we’re tight on resources as it is.
>
> That said, if we’re going to accept apps, we need some (reasonable) criteria 
> for acceptance, along with the proviso that we won’t necessarily always 
> feature the app (since we don’t want to end up featuring 1000 apps on the 
> front page).
>
> Some starting criteria:
>
> * Should currently be available for sale/download on the appropriate app 
> stores.
> * The product needs to have a website where we can link (redirecting into 
> iTunes is not ideal).
> * The product should fit with Cordova’s CoC, since it’s being featured on the 
> front page.
> * The app itself should:
> * be visually appealing and well designed (this is subjective, but no 
> getting around that…)
> * actually work (this would require someone downloading & testing it. 
> Paid apps would need to supply a review copy for free.)
> * be performant (no jank, quick response to user input, etc.)
> * be in production (not just a demo app)
> * be more than just wrapping a remote website
> * Plusses for (but not required):
> * Available source code (so others can learn from the app)
> * Multiple platform support
> * Free or usable trial version so that users can get a good feel for a 
> performant Cordova app
>
> Those are just off the top of my head, so take them as you will. :-)
>
> ~ Kerri
>
>> On Jul 24, 2017, at 19:24, Shazron  wrote:
>>
>> https://cordova.apache.org
>>
>> Are we still accepting apps? How do we select?
>> Right now there are 12. This relates to the Xmind request to dev@
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Highlighting top issues w/ JIRA boards and labels

[Filip Maj]

Thanks for tweaking your workflow Shaz.

FWIW I like the fixVersion field, and I don't think it's incompatible
with the backlog/*-next labels - feels like the two can live
side-by-side.

Taking a look at the board configuration, it looks like only those
blessed by Apache Infra to have JIRA Karma can create boards in the
first place (I think that right now is Steve, Shaz and me). As for
board detail, there is no 'description' field or some such, just Board
Name. So to your first issue, we could change the board name to better
reflect what they intend. Any preference to how to name them?

As for board permissions, the board creator can individually add users
to the admin list for the boards. Most of these boards are owned by
Steve right now (I own the docs-next board). It looks like JIRA can
also add "Groups" to the Board Admin list, but I don't see a cordova
dev-list or some such group. I'll try pinging INFRA to see if we can
have a group like cordova-pmc added or something along those lines. In
the mean time, I'll add Steve and Shaz to the admin list for the docs
and backlog boards.

On Sun, Jul 23, 2017 at 12:05 AM, Shazron <shaz...@gmail.com> wrote:
> Thanks Fil!
> I like this organization and consistency (especially for getting new
> contributors up to speed).
>
> As an example, this is what I've done with my existing boards. I have 3:
> cordova-ios@4.4.1 (labelled ios-next, backlog)
> cordova-ios@4.5.0 (labelled backlog)
> cordova-ios@5.0.0 (labelled backlog)
>
> I will remove the first two boards (soon), knowing that I have captured
> them into this new workflow.
>
> ---
> cordova-ios@4.4.1 Board:
> ios-next board is for label ios-next only -- the next ios-version to be
> released is 4.4.1, thus those issues are labelled with ios-next.
> Once I am done with all the issues, I use the Release functionality of the
> board to say that cordova-ios@4.4.1 is a release.
> Currently also labelled with 'backlog', I will remove that label.
>
> cordova-ios@4.5.0 Board:
> labelled backlog so it shows in the backlog. The fix version currently is
> "cordova-ios@4.5.0" to indicate planned release.
> I will remove this Fix Version, and let it remain in the backlog so the
> next version can be ad-hoc and the version number for released would be
> according to semver.
>
> cordova-ios@5.0.0 Board:
> labelled backlog so it shows in the backlog. The fix version is
> "cordova-ios@5.0.0" to indicate planned release.
> This is planned because it should contain breaking changes (API change, iOS
> Support change etc). When the time comes, this will be labelled 'ios-next'
> since it also exists in the backlog. It still has a board for visibility
> (although it can be achieved with a saved filter).
> ---
>
> From the aftermath I will have only two boards:
> ios-next
> cordova-ios@5.0.0 (labelled backlog, fix-version cordova-ios@5.0.0)
>
> After an ios-next release:
> 1. I will triage the backlog for component: ios issues
> 2. Label items for the next release with "ios-next"
> 3. Remove the "backlog" label for these same items
>
> As new issues come in:
> 1.  Triage them into "backlog" label OR
> 2. Triage them into "ios-next"  label
>
> You move an item from the "backlog" to "ios-next (or vice-versa) by
> changing the label.
> Your issue should not have both labels.
>
> =
> ISSUES:
> 1. Right now the 'ios-next' board is just named that, 'ios-next'. It is not
> clearly visible what the next planned version is. I'm not sure how to
> effectively communicate this in JIRA with the Kanban board interface. This
> information should ideally be on the Board itself.
> 2. We should add more Admins for these boards across the PMC
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Jul 22, 2017 at 12:30 PM, Filip Maj <maj@gmail.com> wrote:
>
>> Hi everyone,
>>
>> Over the past little while, I've been trying to wrap my head around
>> what open issues exist within Cordova, which ones are top priority +
>> how we can identify the most pressing issues, and how to bubble those
>> up to the top for PMC members and contributor/committers.
>>
>> With some of the other Adobians, we've slapped together a few JIRA
>> boards that we think can help wrangle the 2,054+ unresolved issues in
>> JIRA [1]. The idea is to use two labels to differentiate between
>> issues identified as "we need to fix this for the next release" and
>> "we need to fix this at some point in the future."
>>
>> One board is called the "Cordova Backlog" [2]. It shows open or in
>> progress issu

Re: [CORE PLUGINS][DISCUSS] Roadmap 2017

[Filip Maj]

By the way I think the details around how to handle INTEGRATED plugins
is the last discussion point left to clarify for the plugin audit /
core plugin roadmap next steps. After that we can start cranking on
the plugins and axing/updating/integrating them.

On Sun, Jul 23, 2017 at 10:57 AM, Filip Maj <maj@gmail.com> wrote:
> Thanks for the breakdown. I'll move discussion on this topic into the
> issue you linked to.
>
> On Sat, Jul 22, 2017 at 11:30 PM, Shazron <shaz...@gmail.com> wrote:
>> Thanks for all this work Fil!
>>
>> Let me clarify https://issues.apache.org/jira/browse/CB-12903 - this task
>> is to list integration issues with respect to users trying to install older
>> versions of the plugin. A lot of this can be mitigated with the engines
>> tag/key but we haven't been using it for the plugins (like
>> cordova-plugin-console), so if someone did try to install the older version
>> of the plugin, it will cause issues.
>>
>> In the case of iOS, and I'm sure Android as well, it relates to the
>> "namespacing" of the integrated plugin.
>> I'm not sure in the case of Android, if the classloader tries to load a
>> class with the same namespace that is already loaded, what happens -- I
>> assume the attempted class that was to be loaded won't be loaded.
>>
>> For iOS, it will create a linker error since it will be a duplicate symbol.
>>
>> To fix this, we can rename the classes, but then it will just be a native
>> side fix. For JavaScript, we want the integrated plugin's native code to
>> prevail (thus it's JavaScript not to be clobbered), not the older version
>> of the plugin -- we can discuss this more at length in the issue.
>>
>>
>>
>> On Sat, Jul 22, 2017 at 12:43 PM, Filip Maj <maj@gmail.com> wrote:
>>
>>> I just wanted to provide an update on the general topic of modernizing
>>> the core plugins and tracking specific next steps.
>>>
>>> I've been doing my best to work through some of the details and open
>>> questions that came up as part of the Core Plugins Roadmap top-level
>>> issue [1].  In my opinion, this issue is a high priority to execute on
>>> as a) it would make cordova more spec-relevant and inch closer towards
>>> APIs that are showing up natively in the browser and b) would reduce
>>> the total plugin/API surface area the cordova PMC is responsible for.
>>> With over two thousand open or in progress issues in JIRA, I feel like
>>> doing everything we can to make maintenance of cordova sustainable is
>>> not only in the best interest of the cordova PMC but also for the
>>> community.
>>>
>>> In particular, here are some steps I've taken:
>>>
>>>  - I've gone through and summarized next steps and filed specific
>>> issues for plugins marked as "KEEP". For some of these, we don't need
>>> to do anything [2]. For other plugins marked "KEEP", the work involves
>>> possibly sunsetting certain specific platforms' code (e.g. vibration
>>> [3] or battery status [4]). The "KEEP" plugins, generally speaking,
>>> probably require the least amount of work in the short-term.
>>>  - I have started (but not yet finished!) working through the plugins
>>> marked "SUNSET", for example the file-transfer plugin [5]. As I'm
>>> working through and formalizing next steps, it's looking like this
>>> tends to be quite involved - many sub-steps and lots of little things
>>> to do. However, I think executing on these sooner rather than later
>>> makes cordova more sustainable from a maintenance perspective sooner,
>>> so I'd like to see us put progress into this. I still have to go
>>> through the rest of the "SUNSET" plugins and write up similar next
>>> steps / encapsulate those into JIRA issues.
>>>  - I have not yet started going through the plugins marked
>>> "INTEGRATE". I see that Shaz has filed a subtask here about "INTEGRATE
>>> plugin steps" [6], but I'm not exactly sure what you intended with
>>> that. Shaz, can you clarify?
>>>
>>> I've also been tagging all of these Core Plugin Roadmap issues,
>>> whether they are integrate, keep or sunset, with the "plugins-next"
>>> label as described in my recent breakdown of surfacing priority issues
>>> [7].
>>>
>>> As always, questions/comments/highfives welcome.
>>>
>>> Cheers,
>>> Fil
>>>
>>> [1] https://issues.apache.org/jira/browse/CB-12708
>>> 

Re: [CORE PLUGINS][DISCUSS] Roadmap 2017

[Filip Maj]

Thanks for the breakdown. I'll move discussion on this topic into the
issue you linked to.

On Sat, Jul 22, 2017 at 11:30 PM, Shazron <shaz...@gmail.com> wrote:
> Thanks for all this work Fil!
>
> Let me clarify https://issues.apache.org/jira/browse/CB-12903 - this task
> is to list integration issues with respect to users trying to install older
> versions of the plugin. A lot of this can be mitigated with the engines
> tag/key but we haven't been using it for the plugins (like
> cordova-plugin-console), so if someone did try to install the older version
> of the plugin, it will cause issues.
>
> In the case of iOS, and I'm sure Android as well, it relates to the
> "namespacing" of the integrated plugin.
> I'm not sure in the case of Android, if the classloader tries to load a
> class with the same namespace that is already loaded, what happens -- I
> assume the attempted class that was to be loaded won't be loaded.
>
> For iOS, it will create a linker error since it will be a duplicate symbol.
>
> To fix this, we can rename the classes, but then it will just be a native
> side fix. For JavaScript, we want the integrated plugin's native code to
> prevail (thus it's JavaScript not to be clobbered), not the older version
> of the plugin -- we can discuss this more at length in the issue.
>
>
>
> On Sat, Jul 22, 2017 at 12:43 PM, Filip Maj <maj@gmail.com> wrote:
>
>> I just wanted to provide an update on the general topic of modernizing
>> the core plugins and tracking specific next steps.
>>
>> I've been doing my best to work through some of the details and open
>> questions that came up as part of the Core Plugins Roadmap top-level
>> issue [1].  In my opinion, this issue is a high priority to execute on
>> as a) it would make cordova more spec-relevant and inch closer towards
>> APIs that are showing up natively in the browser and b) would reduce
>> the total plugin/API surface area the cordova PMC is responsible for.
>> With over two thousand open or in progress issues in JIRA, I feel like
>> doing everything we can to make maintenance of cordova sustainable is
>> not only in the best interest of the cordova PMC but also for the
>> community.
>>
>> In particular, here are some steps I've taken:
>>
>>  - I've gone through and summarized next steps and filed specific
>> issues for plugins marked as "KEEP". For some of these, we don't need
>> to do anything [2]. For other plugins marked "KEEP", the work involves
>> possibly sunsetting certain specific platforms' code (e.g. vibration
>> [3] or battery status [4]). The "KEEP" plugins, generally speaking,
>> probably require the least amount of work in the short-term.
>>  - I have started (but not yet finished!) working through the plugins
>> marked "SUNSET", for example the file-transfer plugin [5]. As I'm
>> working through and formalizing next steps, it's looking like this
>> tends to be quite involved - many sub-steps and lots of little things
>> to do. However, I think executing on these sooner rather than later
>> makes cordova more sustainable from a maintenance perspective sooner,
>> so I'd like to see us put progress into this. I still have to go
>> through the rest of the "SUNSET" plugins and write up similar next
>> steps / encapsulate those into JIRA issues.
>>  - I have not yet started going through the plugins marked
>> "INTEGRATE". I see that Shaz has filed a subtask here about "INTEGRATE
>> plugin steps" [6], but I'm not exactly sure what you intended with
>> that. Shaz, can you clarify?
>>
>> I've also been tagging all of these Core Plugin Roadmap issues,
>> whether they are integrate, keep or sunset, with the "plugins-next"
>> label as described in my recent breakdown of surfacing priority issues
>> [7].
>>
>> As always, questions/comments/highfives welcome.
>>
>> Cheers,
>> Fil
>>
>> [1] https://issues.apache.org/jira/browse/CB-12708
>> [2] https://issues.apache.org/jira/browse/CB-12709
>> [3] https://issues.apache.org/jira/browse/CB-13045
>> [4] https://issues.apache.org/jira/browse/CB-13046
>> [5] https://issues.apache.org/jira/browse/CB-13052
>> [6] https://issues.apache.org/jira/browse/CB-12903
>> [7] http://markmail.org/message/nhr7uqvtdbg23fyg
>>
>> On Thu, Jun 8, 2017 at 5:17 PM, Filip Maj <maj@gmail.com> wrote:
>> > Great job, awesome to see progress on this. 6 plugins to sunset, 5 to
>> > integrate! Huge progress.
>> >
>> > On Thu, Jun 8, 2017 at 7:09 PM, Shazron <shaz...@gm

Re: [CORE PLUGINS][DISCUSS] Roadmap 2017

[Filip Maj]

I just wanted to provide an update on the general topic of modernizing
the core plugins and tracking specific next steps.

I've been doing my best to work through some of the details and open
questions that came up as part of the Core Plugins Roadmap top-level
issue [1].  In my opinion, this issue is a high priority to execute on
as a) it would make cordova more spec-relevant and inch closer towards
APIs that are showing up natively in the browser and b) would reduce
the total plugin/API surface area the cordova PMC is responsible for.
With over two thousand open or in progress issues in JIRA, I feel like
doing everything we can to make maintenance of cordova sustainable is
not only in the best interest of the cordova PMC but also for the
community.

In particular, here are some steps I've taken:

 - I've gone through and summarized next steps and filed specific
issues for plugins marked as "KEEP". For some of these, we don't need
to do anything [2]. For other plugins marked "KEEP", the work involves
possibly sunsetting certain specific platforms' code (e.g. vibration
[3] or battery status [4]). The "KEEP" plugins, generally speaking,
probably require the least amount of work in the short-term.
 - I have started (but not yet finished!) working through the plugins
marked "SUNSET", for example the file-transfer plugin [5]. As I'm
working through and formalizing next steps, it's looking like this
tends to be quite involved - many sub-steps and lots of little things
to do. However, I think executing on these sooner rather than later
makes cordova more sustainable from a maintenance perspective sooner,
so I'd like to see us put progress into this. I still have to go
through the rest of the "SUNSET" plugins and write up similar next
steps / encapsulate those into JIRA issues.
 - I have not yet started going through the plugins marked
"INTEGRATE". I see that Shaz has filed a subtask here about "INTEGRATE
plugin steps" [6], but I'm not exactly sure what you intended with
that. Shaz, can you clarify?

I've also been tagging all of these Core Plugin Roadmap issues,
whether they are integrate, keep or sunset, with the "plugins-next"
label as described in my recent breakdown of surfacing priority issues
[7].

As always, questions/comments/highfives welcome.

Cheers,
Fil

[1] https://issues.apache.org/jira/browse/CB-12708
[2] https://issues.apache.org/jira/browse/CB-12709
[3] https://issues.apache.org/jira/browse/CB-13045
[4] https://issues.apache.org/jira/browse/CB-13046
[5] https://issues.apache.org/jira/browse/CB-13052
[6] https://issues.apache.org/jira/browse/CB-12903
[7] http://markmail.org/message/nhr7uqvtdbg23fyg

On Thu, Jun 8, 2017 at 5:17 PM, Filip Maj <maj@gmail.com> wrote:
> Great job, awesome to see progress on this. 6 plugins to sunset, 5 to
> integrate! Huge progress.
>
> On Thu, Jun 8, 2017 at 7:09 PM, Shazron <shaz...@gmail.com> wrote:
>> Deadline has passed for:
>> https://issues.apache.org/jira/browse/CB-12708
>>
>> I believe I captured consensus in the issues as best I could. If there was
>> no consensus, the status quo prevails (KEEP).
>>
>> On Tue, May 30, 2017 at 12:58 PM, Shazron <shaz...@gmail.com> wrote:
>>
>>> Good point, I can imagine that after June 5 they will possibly bake things
>>> into Safari and improve WKWebView, but that will only apply to iOS 11
>>> onwards and would not affect most decisions since we need to be backwards
>>> compat for quite a while.
>>>
>>> For June 1st, it looks like consensus is there for the majority of the
>>> plugins. I'm comfortable to move the deadline to June 6th. If there are any
>>> earth-shattering announcements from Apple, we can bump it up one more week.
>>>
>>>
>>> On Tue, May 30, 2017 at 2:07 AM, julio cesar sanchez <
>>> jcesarmob...@gmail.com> wrote:
>>>
>>>> With the WWDC being next week, should we wait a few more days before
>>>> making
>>>> the final decision?
>>>> After a sneak peek into iOS 11 announcements maybe we can make a better
>>>> decision
>>>>
>>>> 2017-05-22 18:47 GMT+02:00 Shazron <shaz...@gmail.com>:
>>>>
>>>> > Deadline of June 1st is in 11 days, so get your comments in.
>>>> >
>>>> > On Wed, Apr 26, 2017 at 1:01 PM, Shazron <shaz...@gmail.com> wrote:
>>>> >
>>>> > > I'm going to put a deadline of June 1st, 2017 to wrap up discussion of
>>>> > the
>>>> > > Roadmap, we need it to be finalized by then if not it will just be
>>>> left
>>>> > in
>>>> > > the wind like previous proposals.

Highlighting top issues w/ JIRA boards and labels

[Filip Maj]

Hi everyone,

Over the past little while, I've been trying to wrap my head around
what open issues exist within Cordova, which ones are top priority +
how we can identify the most pressing issues, and how to bubble those
up to the top for PMC members and contributor/committers.

With some of the other Adobians, we've slapped together a few JIRA
boards that we think can help wrangle the 2,054+ unresolved issues in
JIRA [1]. The idea is to use two labels to differentiate between
issues identified as "we need to fix this for the next release" and
"we need to fix this at some point in the future."

One board is called the "Cordova Backlog" [2]. It shows open or in
progress issues for _all_ components / repos within Cordova that are
tagged with the 'backlog' label. I think this board helps to
identify/aggregate triaged issues that committers/PMC members feel are
important enough to address at some point - but not necessarily for
the next release. It also gives a nice high-level overview of Cordova
as a whole since it shows issues across all repos. To make an issue
show up in this board, simply add the 'backlog' label to a JIRA issue.

To complement this, and make working towards the next release for
particular components easier, we've added a set of boards we've called
"Next". These boards are per-component (or roughly, per group of
related components), and show open, in progress and completed issues.
The idea with these boards is to give specific repo maintainers +
contributors a shared todo list as they work towards nailing a
release. We already had a "cordova-next" board in the past which was
mainly used in prep for major version releases of the tooling - this
board has been renamed "tools-next." The specific boards created are:
 - browser-next [3] for the cordova-browser platform
 - docs-next [4] for cordova-docs
 - plugins-next [5] for all cordova plugins
 - android-next [6] for cordova-android
 - tools-next [7] for all cordova tooling (cli, lib, fetch, create, etc.)
 - ios-next [8] for cordova-ios
 - windows-next [9] for cordova-windows

To make an issue show up in one of these, apply the relevant *-next
label to an issue, i.e. android-next, or docs-next, or browser-next.
The "release" link available on these boards could also be used to
help create changelogs.

So, to summarize:
 - hoping this can create visibility and a shared backlog / work list
to help with collaboration between contributors
 - hoping a consistent approach across repos can help increase
transparency and lower confusion as contributors work across repos

Open to any comments or questions! My goal with this is to try to
create a shared workflow for contributors, that is relatively
consistent across components, in order to increase ease of
collaboration - this is not set in stone, but rather a first stab, so
I am open to all ideas to try to make this more accessible for
everyone.

Cheers,
Fil


[1] 
https://issues.apache.org/jira/secure/ConfigureReport.jspa?filterid=12320364=components=12312420=com.atlassian.jira.plugin.system.reports%3Asinglelevelgroupby=Next
[2] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=195
[3] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=193
[4] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=198
[5] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=194
[6] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=190
[7] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=171
[8] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=192
[9] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=191

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: cordova-lib proposal on test directory reorganization

[Filip Maj]

I'm planning on merging this in later today if there are no more
comments. So far only positive ones!

On Mon, Jun 26, 2017 at 7:45 AM, Filip Maj <maj@gmail.com> wrote:
> Still looking for a bit more feedback, please take a look if you have
> time! Thanks Anis for your feedback :)
>
> Don't worry about the diff / changeset (~1900 files changed!), the PR
> description, I think, summarizes the changes well enough. Almost all
> the changes are renaming files and tweaking the directory structure.
>
> I am thinking of merging this in Wednesday if I get no more comments,
> or possibly sooner if I get nothing but positive feedback. They are
> big directory structure changes, and the sooner we can get this in,
> the less rebase headache will exist.
>
> Thanks!
> Fil
>
> On Thu, Jun 22, 2017 at 5:41 PM, Filip Maj <maj@gmail.com> wrote:
>> Proposal up in PR form here: https://github.com/apache/cordova-lib/pull/568
>>
>> tl;dr consolidating `spec-cordova/` and `spec-plugman` directories
>> into one, setting up to for one-unit-test-spec.js per source-module.js
>> file.
>>
>> Looking for eyes and feedback! If you have any, please drop comments in the 
>> PR.
>>
>> Thanks!
>> Fil

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: cordova-lib proposal on test directory reorganization

[Filip Maj]

Still looking for a bit more feedback, please take a look if you have
time! Thanks Anis for your feedback :)

Don't worry about the diff / changeset (~1900 files changed!), the PR
description, I think, summarizes the changes well enough. Almost all
the changes are renaming files and tweaking the directory structure.

I am thinking of merging this in Wednesday if I get no more comments,
or possibly sooner if I get nothing but positive feedback. They are
big directory structure changes, and the sooner we can get this in,
the less rebase headache will exist.

Thanks!
Fil

On Thu, Jun 22, 2017 at 5:41 PM, Filip Maj <maj@gmail.com> wrote:
> Proposal up in PR form here: https://github.com/apache/cordova-lib/pull/568
>
> tl;dr consolidating `spec-cordova/` and `spec-plugman` directories
> into one, setting up to for one-unit-test-spec.js per source-module.js
> file.
>
> Looking for eyes and feedback! If you have any, please drop comments in the 
> PR.
>
> Thanks!
> Fil

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cloudapp CI is down, builds moving to Travis

[Filip Maj]

Nice! It's also awesome to have the CI code end up in the yml files
inside the repositories, rather than jenkins job configs on cloudapps.

On Fri, Jun 23, 2017 at 1:38 AM,  <alsoro...@apache.org> wrote:
> So I've finally managed to get it working, here's an example of PR for 
> battery-status plugin:
> https://github.com/apache/cordova-plugin-battery-status/pull/55
>
> Now I'm working to propagate it through other plugin repositories. Soon we'll 
> have plugin PRs covered again!
>
> -Original Message-
> From: Filip Maj [mailto:maj@gmail.com]
> Sent: Wednesday, June 21, 2017 7:49 PM
> To: dev@cordova.apache.org
> Subject: Re: Cloudapp CI is down, builds moving to Travis
>
> I know Sauce Connect pretty well from my days working at Sauce Labs :)
>
> Not sure if appropriate for the dev list - if not, message me on slack and 
> I'd be happy to help any way I can.
>
> On Wed, Jun 21, 2017 at 11:34 AM,  <alsoro...@apache.org> wrote:
>> Yeah, forgot to give a link to JIRA issue:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissue
>> s.apache.org%2Fjira%2Fbrowse%2FCB-12935=02%7C01%7Cv-alsoro%40micr
>> osoft.com%7C0a08a8f1a3124373201b08d4b8c57105%7C72f988bf86f141af91ab2d7
>> cd011db47%7C1%7C0%7C636336605526115838=YOC2cn07fgQxDZ8dgOAl%2Frd
>> RsLMvgJGUm%2B%2BTHmol54M%3D=0
>>
>> For now, I'm wrestling with Sauce Connect and jwt plugins for Travis in an 
>> attempt to make secure variables work for PRs from external forks. Besides 
>> that, there is nothing holding us from running these builds, so if you have 
>> any insight on that, I'd be glad to hear it.
>>
>> -Original Message-
>> From: Filip Maj [mailto:maj@gmail.com]
>> Sent: Wednesday, June 21, 2017 4:33 PM
>> To: dev@cordova.apache.org
>> Subject: Re: Cloudapp CI is down, builds moving to Travis
>>
>> Any JIRA issues we should look at to track progress?
>>
>> Alex, what can we do to assist? seems like a lot of work - let us know!
>>
>> On Wed, Jun 21, 2017 at 5:39 AM,  <alsoro...@apache.org> wrote:
>>> Our Plugins testing CI (Jenkins) is officially dead now.
>>> We're migrating all the jobs to Travis and AppVeyor, but for the time
>>> being, all PRs to the plugin repos are not being tested. I'm working
>>> to enable Travis and AppVeyor builds as soon as possible, but there
>>> are some unexpected hassle with encrypted env.variables.
>>>
>>> Will keep you posted.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

cordova-lib proposal on test directory reorganization

[Filip Maj]

Proposal up in PR form here: https://github.com/apache/cordova-lib/pull/568

tl;dr consolidating `spec-cordova/` and `spec-plugman` directories
into one, setting up to for one-unit-test-spec.js per source-module.js
file.

Looking for eyes and feedback! If you have any, please drop comments in the PR.

Thanks!
Fil

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cloudapp CI is down, builds moving to Travis

[Filip Maj]

I know Sauce Connect pretty well from my days working at Sauce Labs :)

Not sure if appropriate for the dev list - if not, message me on slack
and I'd be happy to help any way I can.

On Wed, Jun 21, 2017 at 11:34 AM,  <alsoro...@apache.org> wrote:
> Yeah, forgot to give a link to JIRA issue:
> https://issues.apache.org/jira/browse/CB-12935
>
> For now, I'm wrestling with Sauce Connect and jwt plugins for Travis in an 
> attempt to make secure variables work for PRs from external forks. Besides 
> that, there is nothing holding us from running these builds, so if you have 
> any insight on that, I'd be glad to hear it.
>
> -----Original Message-
> From: Filip Maj [mailto:maj@gmail.com]
> Sent: Wednesday, June 21, 2017 4:33 PM
> To: dev@cordova.apache.org
> Subject: Re: Cloudapp CI is down, builds moving to Travis
>
> Any JIRA issues we should look at to track progress?
>
> Alex, what can we do to assist? seems like a lot of work - let us know!
>
> On Wed, Jun 21, 2017 at 5:39 AM,  <alsoro...@apache.org> wrote:
>> Our Plugins testing CI (Jenkins) is officially dead now.
>> We're migrating all the jobs to Travis and AppVeyor, but for the time
>> being, all PRs to the plugin repos are not being tested. I'm working
>> to enable Travis and AppVeyor builds as soon as possible, but there
>> are some unexpected hassle with encrypted env.variables.
>>
>> Will keep you posted.
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cloudapp CI is down, builds moving to Travis

[Filip Maj]

Any JIRA issues we should look at to track progress?

Alex, what can we do to assist? seems like a lot of work - let us know!

On Wed, Jun 21, 2017 at 5:39 AM,   wrote:
> Our Plugins testing CI (Jenkins) is officially dead now.
> We're migrating all the jobs to Travis and AppVeyor, but for the time being,
> all PRs to the plugin repos are not being tested. I'm working to enable
> Travis and AppVeyor builds as soon as possible, but there are some
> unexpected hassle with encrypted env.variables.
>
> Will keep you posted.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Hello

[Filip Maj]

Welcome Georgios!

Nice to e-meet you, I'm Fil.

Thanks for reaching out about where and how to contribute - we really
appreciate it.

The easyfix stuff Julio pointed to is a great place to start and get
your bearings on how the issue tracker works, and hopefully you can
start there to figure out how to send good pull requests and get
reviews on any changes you want to make.

Recently, the chair of Cordova' Project Management Committee (PMC),
Shazron, sent a report about the health of this project to the Apache
Board [1]. If you're curious what issues are top-of-mind for
committers to this project, that's a quick read to get up to speed.

Longer-term, the area where Cordova committers have the most trouble
keeping up is with the mountain of pull requests issued to all the
cordova-plugin-* repositories, as well as the most popular platform
repositories (cordova-ios, cordova-android, cordova-windows and
cordova-browser). If I had a personal choice in a direction to steer
your contributions, it would be reviewing and testing these pull
requests. However, I understand that's a tall task and is a lot to ask
for :)

Anyways, if you have any questions at all, feel free to reply back
here. We also hang out on Slack for informal chats [2], if that's your
cup of tea - I'm filmaj on there.

Once again, welcome, and hope to see your contributions soon :)

Best,
Fil Maj

[1] https://github.com/cordova/apache-board-reports/blob/master/2017/2017-06.md
[2] slack.cordova.io

On Tue, Jun 20, 2017 at 6:47 AM, Georgios Galatoulas
 wrote:
> Thank you Julio,
>
> Will do !
>
> On 20 June 2017 at 12:46, julio cesar sanchez 
> wrote:
>
>> Welcome Georgios,
>>
>> If you want to contribute with bug fixing, here you have the list of
>> "easyfix" issues http://easyfix.cordova.io. or all the issues
>> http://issues.cordova.io.
>> If you find issues you can also report them there, reporting issues is also
>> contributing.
>>
>> Feel free to join the Cordova Slack http://slack.cordova.io/
>>
>>
>> 2017-06-20 13:30 GMT+02:00 Georgios Galatoulas <
>> georgiosgalatou...@gmail.com
>> >:
>>
>> > Hello guys,
>> >
>> > I am Georgios, and I work as Mobile Developer at Masabi. I am Mobile Dev
>> > for a while but I am totally new in open source projects.
>> > I am currently working on our hybrid app which uses Cordova.
>> >
>> > I hope I can contribute whenever possible and looking forward to speak
>> with
>> > you guys.
>> >
>> > I hope this is enough for my intro. Please let me know if I miss
>> anything I
>> > need to mention.
>> >
>> > --
>> > Georgios J. Galatoulas
>> >
>>
>
>
>
> --
> Georgios J. Galatoulas

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DRAFT] Apache Cordova Board Report - June 2017

[Filip Maj]

Just one nit:

"have request Gitbox access" --> "have requested Gitbox access"

LGTM otherwise!

On Sun, Jun 18, 2017 at 3:40 PM,   wrote:
> LGTM.
>
> Sent from my phone.
>
> ___
> Kerri Shotts
> photoKandy Studios, LLC
>
> On the Web: http://www.photokandy.com/
>
> Social Media:
>   Twitter: @photokandy, http://twitter.com/photokandy
>   Tumblr: http://photokandy.tumblr.com/
>   Github: https://github.com/kerrishotts
> https://github.com/organizations/photokandyStudios
>   CoderWall: https://coderwall.com/kerrishotts
>
> Apps on the Apple Store:
>   
> https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828
>
> Books:
>  http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book
>   http://www.packtpub.com/phonegap-social-app-development/book
>
>> On Jun 18, 2017, at 15:13, Shazron  wrote:
>>
>> Please review and comment if necessary.
>>
>> I would like a couple of +1 or LGTM before I send it off on Monday
>>
>> https://github.com/cordova/apache-board-reports/blob/master/2017/2017-06.md

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Android] Let's drop support for Jellybean

[Filip Maj]

Reviving this thread! Sorry for the late reply.

Regarding Trevor's question:
> Just for consideration however, what do we actually gain by dropping
> official support? Are there compat libraries or tests we can drop after
> this?

>From a testing/CI perspective, it becomes much more tenable to keep up
with pull requests and ensure changes are validated on the platforms
we support. We currently leverage Sauce Labs to run tests on emulators
on Android, and Sauce dropped support for all Android versions up to
and including 4.3 [1]. So, from a selfish perspective, as a cordova
dev, dropping 4.3 and below support makes _my_ life easier as I don't
have to manually test on earlier versions of Android.

Not sure if there are other, less-selfish reasons? Ping Simon + Joe.

Also, instead of letting this thread die a quiet death, may I suggest
that whatever decision is made here, we file as issues and chalk up
for the next cordova-android major release?

[1] 
https://wiki.saucelabs.com/display/DOCS/2017/03/30/EOL+for+Android+4.0%2C+4.1%2C+4.2%2C+and+4.3+Automated+Mobile+App+Testing

On Sun, Feb 26, 2017 at 4:36 PM, Trevor Brindle <tabrin...@gmail.com> wrote:
> I don't think it is unreasonable to drop support for an OS that had its
> first release in July of 2012 (4.1 is almost 5 years old), especially
> considering the Cordova support policy for iOS.
>
> Realistically, I think it's hard to justify support for before 4.4. Less
> than 10% of our customers are on 4.4 or earlier as a whole, and less than
> 10% of them actually use our apps regularly.
>
> Just for consideration however, what do we actually gain by dropping
> official support? Are there compat libraries or tests we can drop after
> this?
>
> On Sun, Feb 26, 2017 at 12:10 PM Simon MacDonald <simon.macdon...@gmail.com>
> wrote:
>
> I would happily drop support for anything less than API level 19 in the
> next cordova-android major release.
>
>
> Simon Mac Donald
> http://simonmacdonald.com
>
> On Sun, Feb 26, 2017 at 10:56 AM, Filip Maj <maj@gmail.com> wrote:
>
>> As much as I personally would like to do so, I wonder what the
>> reaction among consumers of cordova would be.
>>
>> On Sun, Feb 26, 2017 at 1:39 AM, Jesse <purplecabb...@gmail.com> wrote:
>> > +1
>> > Our CI tests only test as far back as 4.4, so maybe I thought we were
>> > already there.
>> >
>> >
>> >
>> >
>> >
>> > @purplecabbage
>> > risingj.com
>> >
>> > On Fri, Feb 24, 2017 at 12:15 PM, Joe Bowser <bows...@gmail.com> wrote:
>> >
>> >> Hey
>> >>
>> >> Even though everything appears to be working on Jellybean, I know a lot
>> of
>> >> people have been wanting to throw it to the wayside.  Normally, for us
>> to
>> >> drop support for a platform, we have to wait unitl it goes below 10%,
>> but
>> >> since Jellybean consists of three different API versions, and since two
>> of
>> >> those are below the 5% mark, I'm tempted to just toss it by the wayside
>> and
>> >> set the minimum supported version of Android to 4.4.x, or API level 19.
>> >>
>> >> How do people feel about that.  I know in the past, people were super
>> >> passionate about supporting everything, but given that my Android 4.1
>> >> device is an old Nitobi device obtained before we even became Adobe,
>> and it
>> >> took five tries to get it to cooperate with adb, I'm really starting to
>> >> think it's time we dropped Jellybean.
>> >>
>> >> Thoughts?
>> >>
>> >> Joe
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>
>
> --
> TrevorBrindle
> Lead Hybrid Mobile Engineer
> SHOP•COM powered by marketamerica
> C: (407) 450-8700

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [CORE PLUGINS][DISCUSS] Roadmap 2017

[Filip Maj]

Great job, awesome to see progress on this. 6 plugins to sunset, 5 to
integrate! Huge progress.

On Thu, Jun 8, 2017 at 7:09 PM, Shazron  wrote:
> Deadline has passed for:
> https://issues.apache.org/jira/browse/CB-12708
>
> I believe I captured consensus in the issues as best I could. If there was
> no consensus, the status quo prevails (KEEP).
>
> On Tue, May 30, 2017 at 12:58 PM, Shazron  wrote:
>
>> Good point, I can imagine that after June 5 they will possibly bake things
>> into Safari and improve WKWebView, but that will only apply to iOS 11
>> onwards and would not affect most decisions since we need to be backwards
>> compat for quite a while.
>>
>> For June 1st, it looks like consensus is there for the majority of the
>> plugins. I'm comfortable to move the deadline to June 6th. If there are any
>> earth-shattering announcements from Apple, we can bump it up one more week.
>>
>>
>> On Tue, May 30, 2017 at 2:07 AM, julio cesar sanchez <
>> jcesarmob...@gmail.com> wrote:
>>
>>> With the WWDC being next week, should we wait a few more days before
>>> making
>>> the final decision?
>>> After a sneak peek into iOS 11 announcements maybe we can make a better
>>> decision
>>>
>>> 2017-05-22 18:47 GMT+02:00 Shazron :
>>>
>>> > Deadline of June 1st is in 11 days, so get your comments in.
>>> >
>>> > On Wed, Apr 26, 2017 at 1:01 PM, Shazron  wrote:
>>> >
>>> > > I'm going to put a deadline of June 1st, 2017 to wrap up discussion of
>>> > the
>>> > > Roadmap, we need it to be finalized by then if not it will just be
>>> left
>>> > in
>>> > > the wind like previous proposals.
>>> > >
>>> > > This gives us a month, more than enough I think, to nail this down --
>>> > also
>>> > > since most of the Adobe team will be away on conferences (like
>>> PhoneGap
>>> > Day
>>> > > EU 2017 http://pgday.phonegap.com/eu2017/ -- see you there if you are
>>> > > going) so this extra time will help.
>>> > >
>>> > >
>>> > >
>>> > > On Tue, Apr 25, 2017 at 7:11 PM, Shazron  wrote:
>>> > >
>>> > >> The PR for the Plugin Audit is originally here:
>>> > https://github.com/cordo
>>> > >> va/cordova-discuss/pull/58
>>> > >>
>>> > >> On Tue, Apr 25, 2017 at 6:55 PM, Shazron  wrote:
>>> > >>
>>> > >>> This is the start of a conversation:
>>> > >>> https://issues.apache.org/jira/browse/CB-12708
>>> > >>>
>>> > >>> Take these two issues below into consideration:
>>> > >>>
>>> > >>> 1. Cordova's plugin audit sometime back:
>>> > >>> https://github.com/stevengill/cordova-discuss/blob/836ce2c07
>>> > >>> d7c28ee09509cd8a676886aebc21a28/proposals/PluginsAudit2015/audit.md
>>> > >>>
>>> > >>> 2. The Adobe team's commitment statement w.r.t core plugins:
>>> > >>> https://blog.phonegap.com/our-continued-commitment-bca4121f5d39
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>
>>> > >
>>> >
>>>
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [NOTICE] Intent on moving to Github

[Filip Maj]

That's really helpful Carlos, thanks!

On Wed, Jun 7, 2017 at 12:47 AM, Steven Gill <stevengil...@gmail.com> wrote:
> Thanks Carlos! Very useful information!
>
> On Tue, Jun 6, 2017 at 5:28 PM, Carlos Santana <csantan...@gmail.com> wrote:
>
>> ASF will allow it, other projects already showed interest and at ApacheCon
>> they made it public that they will allow it to any project
>>
>> My incubator project OpenWhisk is the first one to work out all the kinks
>>
>> For now let know everyone that wants write access, specially those that are
>> repo owners and usually in charge of merging PRs to:
>> 1. associate your github id in id.apache.org profile
>> 2. enable 2FA in Github.com
>> 3. show up properly under whimsy
>> https://whimsy.apache.org/roster/committee/cordova
>>
>> Once the repos are transferred, a Github team will be created
>> cordova-committers and folks that go thru gitbox setup will be added to
>> this team,  this team will have write access to all
>> github.com/apache/cordova* repos
>>
>> Once transferred need to make it clear to all committers to reconfigure
>> their git upstream, and no longer write to git-wip
>>
>> other projects that moved over like traffic server, went ahead and migrated
>> all the JIRA Issues to Github Issues, a topic for another thread :-)
>>
>> let me know how I can help, will be glad
>>
>> --Carlos
>>
>>
>> On Tue, Jun 6, 2017 at 6:30 PM Steven Gill <stevengil...@gmail.com> wrote:
>>
>> > Yay! Hope ASF allows us to finally do this!
>> >
>> > On Tue, Jun 6, 2017 at 3:28 PM, Filip Maj <maj@gmail.com> wrote:
>> >
>> > > My one comment is OMG YISS!
>> > >
>> > > On Mon, Jun 5, 2017 at 6:41 PM, Shazron <shaz...@gmail.com> wrote:
>> > > > The Apache Cordova Project Management Committee (PMC) has consensus
>> > that
>> > > we
>> > > > should move primary development of Apache Cordova to Github, from
>> > > Apache's
>> > > > servers (role would be reversed, Apache would then be the mirror
>> now).
>> > > >
>> > > > We are already processing pull requests through Github, although
>> > without
>> > > > write access we couldn't label, or close PRs directly. Enabling of
>> > Issues
>> > > > in Github (to replace JIRA) would be a separate matter, and would
>> > likely
>> > > be
>> > > > on a per-repo basis.
>> > > >
>> > > > Moving is achieved by invitation to the Apache Gitbox project:
>> > > > https://gitbox.apache.org/ (don't get excited if you can log in and
>> > > link,
>> > > > your repo needs to be whitelisted)
>> > > >
>> > > > We would have to file INFRA issues in JIRA to get approval for the
>> > move.
>> > > >
>> > > > We are suggesting a multi-part migration:
>> > > >
>> > > > 1. Top platforms (ios, android, windows, browser)
>> > > > 2. Tools (lib, cli, coho, fetch, common etc) --> we might need a lib
>> > > > breakout first, this is ongoing work
>> > > > 3. All plugins
>> > > >
>> > > > The rest would be on a "as needed" basis.
>> > > >
>> > > > Comments, if any?
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > > For additional commands, e-mail: dev-h...@cordova.apache.org
>> > >
>> > >
>> >
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: move common, fetch and serve to their own repo

[Filip Maj]

Friendly reminder that we will have to update the CI scripts to handle
this now. I believe we are mid-transition away from cloudapp Jenkins
to Travis/AppVeyor now (ping Alex Sorokin).

On Tue, Jun 6, 2017 at 1:03 AM, Steven Gill  wrote:
> I've started moving cordova-common, cordova-fetch and cordova-serve into
> their own repos.
>
> ISSUE: https://issues.apache.org/jira/browse/CB-11980
>
> It is causing some extra jira notifications. Sorry about that!
>
> -Steve

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [NOTICE] Intent on moving to Github

[Filip Maj]

My one comment is OMG YISS!

On Mon, Jun 5, 2017 at 6:41 PM, Shazron  wrote:
> The Apache Cordova Project Management Committee (PMC) has consensus that we
> should move primary development of Apache Cordova to Github, from Apache's
> servers (role would be reversed, Apache would then be the mirror now).
>
> We are already processing pull requests through Github, although without
> write access we couldn't label, or close PRs directly. Enabling of Issues
> in Github (to replace JIRA) would be a separate matter, and would likely be
> on a per-repo basis.
>
> Moving is achieved by invitation to the Apache Gitbox project:
> https://gitbox.apache.org/ (don't get excited if you can log in and link,
> your repo needs to be whitelisted)
>
> We would have to file INFRA issues in JIRA to get approval for the move.
>
> We are suggesting a multi-part migration:
>
> 1. Top platforms (ios, android, windows, browser)
> 2. Tools (lib, cli, coho, fetch, common etc) --> we might need a lib
> breakout first, this is ongoing work
> 3. All plugins
>
> The rest would be on a "as needed" basis.
>
> Comments, if any?

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] Coho Release

[Filip Maj]

I vote +1

* Ran coho audit-license-headers over the coho repo
* Ran coho check-license to ensure all coho source has Apache-compatible
licenses
* Ensured continuous build was green when repos were tagged

On Thu, May 11, 2017 at 10:36 AM, Shazron  wrote:
> Please review and vote on this Tools Release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12793
>
> Coho has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-12793/
>
> The package was published from its corresponding git tag:
> cordova-coho: 1.0.0 (3f2e16cc3c)
>
> Upon a successful vote I will upload the archives to dist/, publish them to
> npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the coho repo
> * Ran coho check-license to ensure all coho source has Apache-compatible
> licenses
> * Ensured continuous build was green when repos were tagged

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[ANNOUNCE] Cordova-Android 6.2.3 released

[Filip Maj]

Tweet: https://twitter.com/apachecordova/status/860551489902657536
Blog: http://cordova.apache.org/announcements/2017/05/04/android-release.html

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] 6.2.3 Android release

[Filip Maj]

The vote has now closed. The results are:

Positive Binding Votes: 3
Filip Maj
Joe Bowser
Shazron Abdullah

The vote has passed.

On Thu, May 4, 2017 at 3:56 PM, Shazron <shaz...@gmail.com> wrote:
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all repo sources have Apache-compatible
> licenses
> * verified signatures and hashes on tarballs
> * on Android SDK Tools 26.0.1 and 26.0.2 I ran (all passed):
>   - bin/create
>   - cordova/build
>   - cordova/run --emulator
>   - cordova/run --device to a real device
> * on Android SDK Tools 26.0.1 and 26.0.2 I ran (all passed) with
> cordova-cli@6.5.0:
>   - cordova build
>   - cordova run --emulator
>   - cordova run --device to a real device
>
> On Thu, May 4, 2017 at 11:47 AM, Joe Bowser <bows...@gmail.com> wrote:
>
>> I vote +1
>>
>> * Ran mobile spec testing the new emulator-handling code, via `cordova
>> run --emulator`, w/ latest plugin code.
>> * Ensured can use bin/create to create project
>> * Ran empty project created by bin/create against emulator
>> * Created a project with the CLI and ran it on the emulator
>>
>> On Tue, May 2, 2017 at 5:02 PM, Filip Maj <maj@gmail.com> wrote:
>>
>> > Please review and vote on this 6.2.3 Android Release by replying to
>> > this email (and keep discussion on the DISCUSS thread - am
>> > piggy-backing on the 6.2.2 release DISCUSS thread)
>> >
>> > Release issue: https://issues.apache.org/jira/browse/CB-12746
>> >
>> > The archive has been published to
>> > dist/dev: https://dist.apache.org/repos/dist/dev/cordova/CB-12746
>> >
>> > The package was published from its corresponding git tag:
>> > cordova-android: 6.2.3 (c0df73c3)
>> >
>> > Note that you can test it out via:
>> >
>> > cordova platform add https://github.com/apache/cordova-android#6.2.3
>> >
>> > Upon a successful vote I will upload the archive to dist/, publish it
>> > to npm, and post the blog post.
>> >
>> > I have also sent a PR for the blog post related to this release -
>> > reviews requested, please take a look:
>> > https://github.com/apache/cordova-docs/pull/702
>> >
>> > Voting guidelines:
>> > https://github.com/apache/cordova-coho/blob/master/docs/rele
>> ase-voting.md
>> >
>> > Voting will go on for a minimum of 48 hours.
>> >
>> > I vote +1:
>> > * Ran mobile spec on a real device, w/ latest plugin code.
>> > * Ran mobile spec testing the new emulator-handling code, via `cordova
>> > run --emulator`, w/ latest plugin code.
>> > * Ensured can create a new project using cordova-cli, and run on both
>> > device and emulator
>> > * Ensured can use the bin/create script.
>> > * Double-checked reported versions via `cordova/version` script.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>> >
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[ANNOUNCE] May 2017 Plugins Release is out

[Filip Maj]

ze tweet: https://twitter.com/apachecordova/status/859866885914894336
ze blog: http://cordova.apache.org/news/2017/05/01/plugins-release.html

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[VOTE] 6.2.3 Android release

[Filip Maj]

Please review and vote on this 6.2.3 Android Release by replying to
this email (and keep discussion on the DISCUSS thread - am
piggy-backing on the 6.2.2 release DISCUSS thread)

Release issue: https://issues.apache.org/jira/browse/CB-12746

The archive has been published to
dist/dev: https://dist.apache.org/repos/dist/dev/cordova/CB-12746

The package was published from its corresponding git tag:
cordova-android: 6.2.3 (c0df73c3)

Note that you can test it out via:

cordova platform add https://github.com/apache/cordova-android#6.2.3

Upon a successful vote I will upload the archive to dist/, publish it
to npm, and post the blog post.

I have also sent a PR for the blog post related to this release -
reviews requested, please take a look:
https://github.com/apache/cordova-docs/pull/702

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran mobile spec on a real device, w/ latest plugin code.
* Ran mobile spec testing the new emulator-handling code, via `cordova
run --emulator`, w/ latest plugin code.
* Ensured can create a new project using cordova-cli, and run on both
device and emulator
* Ensured can use the bin/create script.
* Double-checked reported versions via `cordova/version` script.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] cordova-android@6.2.2 release

[Filip Maj]

Bad news: we forgot to merge relevant commits from master into the
release branch for this release.

For details, see https://issues.apache.org/jira/browse/CB-12746

I am going to switch to working on getting a 6.2.3 release candidate
together and getting a VOTE thread out for it ASAP.

On Fri, Apr 28, 2017 at 11:48 AM, Steven Gill <stevengil...@gmail.com> wrote:
> Done.
> https://github.com/stevengill/cordova-docs/commit/03b67269efe58ebd1cf12042ec9616bd1d05ea25
>
> On Fri, Apr 28, 2017 at 11:40 AM, Filip Maj <maj@gmail.com> wrote:
>
>> I would put more emphasis on upgrading for users of the latest Android
>> SDK tools. Older cordova-android versions cannot and will not work
>> with the latest SDK tools, so it's really important.
>>
>> On Fri, Apr 28, 2017 at 11:20 AM, Steven Gill <stevengil...@gmail.com>
>> wrote:
>> > Blog Post:
>> > https://github.com/stevengill/cordova-docs/commit/
>> 00bdcf77ad0c924cd2516a1fe79aa3276a9ddc08
>> >
>> > Can't send it as a PR since our github mirrors are down
>> >
>> > On Fri, Apr 21, 2017 at 4:48 PM, Steven Gill <stevengil...@gmail.com>
>> wrote:
>> >
>> >> Need to do another patch release due to android sdk tools being updated
>> by
>> >> google.
>> >>
>> >> Any concerns?
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[BLOG POST][DRAFT] May 2017 Plugins Release

[Filip Maj]

Please review! https://github.com/apache/cordova-docs/pull/701

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] Plugins Release, April 28 2017

[Filip Maj]

The vote has now closed. The results are:

Positive Binding Votes: 3
Filip Maj
Shazron Abdullah
Jesse MacFadyen

The vote has passed.

On Mon, May 1, 2017 at 4:02 PM, Jesse <purplecabb...@gmail.com> wrote:
> I vote +1:
> *Ran coho verify-archives against all .tgz dists
> * All relevant repos are green on http://status.cordova.io
>
>
>
> @purplecabbage
> risingj.com
>
> On Mon, May 1, 2017 at 3:43 PM, Shazron <shaz...@gmail.com> wrote:
>
>> I vote +1:
>> * Ran coho audit-license-headers over the relevant repos
>> * Ran coho check-license to ensure all dependencies and
>> subdependencies have Apache-compatible licenses
>> * All relevant repos are green on http://status.cordova.io
>>
>> On Fri, Apr 28, 2017 at 11:23 AM, Filip Maj <maj@gmail.com> wrote:
>>
>> > Please review and vote on the release of this plugins release by
>> > replying to this email (and keep discussion on the DISCUSS thread).
>> >
>> > Release issue: https://issues.apache.org/jira/browse/CB-12736
>> >
>> > The plugins have been published to dist/dev:
>> > https://dist.apache.org/repos/dist/dev/cordova/CB-12736/
>> >
>> > The packages were published from their corresponding git tags:
>> > cordova-plugin-battery-status: 1.2.4 (dfec094)
>> > cordova-plugin-camera: 2.4.1 (ba9a803)
>> > cordova-plugin-console: 1.0.7 (fa26558)
>> > cordova-plugin-contacts: 2.3.1 (1c27c9a)
>> > cordova-plugin-device-motion: 1.2.5 (04ce0ea)
>> > cordova-plugin-device-orientation: 1.0.7 (7af309f)
>> > cordova-plugin-device: 1.1.6 (eeb48e8)
>> > cordova-plugin-dialogs: 1.3.3 (34cccf6)
>> > cordova-plugin-file: 4.3.3 (06ff0eb)
>> > cordova-plugin-file-transfer: 1.6.3 (720f314)
>> > cordova-plugin-geolocation: 2.4.3 (12fae5b)
>> > cordova-plugin-globalization: 1.0.7 (273e5a6)
>> > cordova-plugin-inappbrowser: 1.7.1 (ff6a765)
>> > cordova-plugin-media: 3.0.1 (2a1ee43)
>> > cordova-plugin-media-capture: 1.4.3 (b78a4b2)
>> > cordova-plugin-network-information: 1.3.3 (710b53d)
>> > cordova-plugin-screen-orientation: 20.1 (8699159)
>> > cordova-plugin-splashscreen: 4.0.3 (85aa605)
>> > cordova-plugin-statusbar: 2.2.3 (77a6ae5)
>> > cordova-plugin-vibration: 2.1.5 (96c4ad6)
>> > cordova-plugin-wkwebview-engine: 1.1.3 (fce6123)
>> >
>> > Upon a successful vote I will upload the archives to dist/, upload
>> > them to npm, and post the corresponding blog post.
>> >
>> > Voting guidelines:
>> > https://github.com/apache/cordova-coho/blob/master/docs/
>> release-voting.md
>> > How to vote on a plugins release at
>> > https://github.com/apache/cordova-coho/blob/master/docs/
>> > plugins-release-process.md#voting
>> >
>> > Voting will go on for a minimum of 48 hours.
>> >
>> > I vote +1:
>> > * Ran coho audit-license-headers over the relevant repos (via coho
>> > prepare-plugins-release)
>> > * Ran mobile spec on these relevant plugins for both Android and iOS.
>> > Summary:
>> >  - Android:
>> >- Created a project w/ cordova-android@6.2.2 and tested on a Google
>> > Pixel device running Android 7.1.2
>> >- One autotest failure: FileAPI resolveLocalFileSystemURL on
>> > cdvfile:// file.spec.147, got error code 1
>> >- Was unable to reproduce the above failure in the File plugin manual
>> > tests.
>> >  - iOS:
>> >- Created a project w/ cordova-ios@4.4.0 and tested on an iPhone 5S
>> > running iOS 10.3.1.
>> >- A few autotest failures:
>> >  - (same as android): FileAPI resolveLocalFileSystemURL on
>> > cdvfile:// file.spec.147, got error code 1
>> >  - filetransfer.spec.8: download file over https, timedout
>> >  - filetransfer.spec.21: able to stop via abort(), timedout
>> >  - media.spec.24: playback rate should be set properly using
>> > setRate, however, running this multiple times shows it passes
>> > sometimes and fails other times with errors in the form:
>> >- 2.9 not to be less than 4
>> >- 2.8 not to be less than 4
>> >… tells me the test might be a little brittle?
>> >  - media.spec.27: should call success or error when stopping a
>> > media that is in starting state.expected false to be true.
>> > * Ensured continuous build was green when repos were tagged. Relevant
>> > C

Re: [DISCUSS] cordova-android@6.2.2 release

[Filip Maj]

I would put more emphasis on upgrading for users of the latest Android
SDK tools. Older cordova-android versions cannot and will not work
with the latest SDK tools, so it's really important.

On Fri, Apr 28, 2017 at 11:20 AM, Steven Gill  wrote:
> Blog Post:
> https://github.com/stevengill/cordova-docs/commit/00bdcf77ad0c924cd2516a1fe79aa3276a9ddc08
>
> Can't send it as a PR since our github mirrors are down
>
> On Fri, Apr 21, 2017 at 4:48 PM, Steven Gill  wrote:
>
>> Need to do another patch release due to android sdk tools being updated by
>> google.
>>
>> Any concerns?
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Plugins Release

[Filip Maj]

Vote thread is up. Please go and test and vote, thanks :D

Related to the failures I mentioned in my vote, Shaz has already filed
relevant issues:

https://issues.apache.org/jira/browse/CB-12699 (experienced this one
on both Android and iOS)
https://issues.apache.org/jira/browse/CB-12701 (just iOS, and just spec.27)

On Thu, Apr 27, 2017 at 1:30 PM, Filip Maj <maj@gmail.com> wrote:
> Alright, the plugins release issue is here:
> https://issues.apache.org/jira/browse/CB-12736
>
> For the plugins that warranted releases, I've got the RCs for them up
> on dist-dev: https://dist.apache.org/repos/dist/dev/cordova/CB-12736/
>
> I probably won't have time to go through all of these and do the
> necessary testing today. I'm planning on doing that tomorrow and the
> vote thread will go out then.
>
> (p.s., used the plugins-releaser thing I've worked on in the
> background here and there that I merged into coho this week for this:
> ./coho prepare-plugins-release)
>
> On Thu, Apr 27, 2017 at 9:18 AM, Steven Gill <stevengil...@gmail.com> wrote:
>> do it!
>>
>> On Wed, Apr 26, 2017 at 12:51 PM, Filip Maj <maj@gmail.com> wrote:
>>
>>> We did some work this week and got a bunch of community PRs merged in
>>> to many plugin repos.
>>>
>>> Anyone have any reasons to not do a release? Anything outstanding
>>> anyone wants to get merged in before moving ahead with a plugins
>>> release? Any other comments on the topic?
>>>
>>> Cheers,
>>> Fil Maj
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[VOTE] Plugins Release, April 28 2017

[Filip Maj]

Please review and vote on the release of this plugins release by
replying to this email (and keep discussion on the DISCUSS thread).

Release issue: https://issues.apache.org/jira/browse/CB-12736

The plugins have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/CB-12736/

The packages were published from their corresponding git tags:
cordova-plugin-battery-status: 1.2.4 (dfec094)
cordova-plugin-camera: 2.4.1 (ba9a803)
cordova-plugin-console: 1.0.7 (fa26558)
cordova-plugin-contacts: 2.3.1 (1c27c9a)
cordova-plugin-device-motion: 1.2.5 (04ce0ea)
cordova-plugin-device-orientation: 1.0.7 (7af309f)
cordova-plugin-device: 1.1.6 (eeb48e8)
cordova-plugin-dialogs: 1.3.3 (34cccf6)
cordova-plugin-file: 4.3.3 (06ff0eb)
cordova-plugin-file-transfer: 1.6.3 (720f314)
cordova-plugin-geolocation: 2.4.3 (12fae5b)
cordova-plugin-globalization: 1.0.7 (273e5a6)
cordova-plugin-inappbrowser: 1.7.1 (ff6a765)
cordova-plugin-media: 3.0.1 (2a1ee43)
cordova-plugin-media-capture: 1.4.3 (b78a4b2)
cordova-plugin-network-information: 1.3.3 (710b53d)
cordova-plugin-screen-orientation: 20.1 (8699159)
cordova-plugin-splashscreen: 4.0.3 (85aa605)
cordova-plugin-statusbar: 2.2.3 (77a6ae5)
cordova-plugin-vibration: 2.1.5 (96c4ad6)
cordova-plugin-wkwebview-engine: 1.1.3 (fce6123)

Upon a successful vote I will upload the archives to dist/, upload
them to npm, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
How to vote on a plugins release at
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos (via coho
prepare-plugins-release)
* Ran mobile spec on these relevant plugins for both Android and iOS. Summary:
 - Android:
   - Created a project w/ cordova-android@6.2.2 and tested on a Google
Pixel device running Android 7.1.2
   - One autotest failure: FileAPI resolveLocalFileSystemURL on
cdvfile:// file.spec.147, got error code 1
   - Was unable to reproduce the above failure in the File plugin manual tests.
 - iOS:
   - Created a project w/ cordova-ios@4.4.0 and tested on an iPhone 5S
running iOS 10.3.1.
   - A few autotest failures:
 - (same as android): FileAPI resolveLocalFileSystemURL on
cdvfile:// file.spec.147, got error code 1
 - filetransfer.spec.8: download file over https, timedout
 - filetransfer.spec.21: able to stop via abort(), timedout
 - media.spec.24: playback rate should be set properly using
setRate, however, running this multiple times shows it passes
sometimes and fails other times with errors in the form:
   - 2.9 not to be less than 4
   - 2.8 not to be less than 4
   … tells me the test might be a little brittle?
 - media.spec.27: should call success or error when stopping a
media that is in starting state.expected false to be true.
* Ensured continuous build was green when repos were tagged. Relevant
CI links (thank you Alex Sorokin for these!):
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-battery-status-commit/23/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-camera-commit/13/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-console-commit/8/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-contacts-commit/11/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-device-commit/10/
 - 
http://cordova-ci.cloudapp.net:8080/view/Pull%20requests/job/cordova-plugin-device-motion-pr/26/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-device-orientation-commit/8/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-dialogs-commit/9/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-file-commit/12/
 - http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-file-transfer-pr/75/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-geolocation-commit/9/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-globalization-commit/11/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-inappbrowser-commit/13/
 - http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/122/
 - 
http://cordova-ci.cloudapp.net:8080/view/Per-commit%20testing/job/cordova-plugin-media-capture-pr/37/
 - 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-network-information-commit/7/
 - 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-screen-orientation-commit/10/
 - http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/48/
 - 

Re: [DISCUSS] Plugins Release

[Filip Maj]

Alright, the plugins release issue is here:
https://issues.apache.org/jira/browse/CB-12736

For the plugins that warranted releases, I've got the RCs for them up
on dist-dev: https://dist.apache.org/repos/dist/dev/cordova/CB-12736/

I probably won't have time to go through all of these and do the
necessary testing today. I'm planning on doing that tomorrow and the
vote thread will go out then.

(p.s., used the plugins-releaser thing I've worked on in the
background here and there that I merged into coho this week for this:
./coho prepare-plugins-release)

On Thu, Apr 27, 2017 at 9:18 AM, Steven Gill <stevengil...@gmail.com> wrote:
> do it!
>
> On Wed, Apr 26, 2017 at 12:51 PM, Filip Maj <maj@gmail.com> wrote:
>
>> We did some work this week and got a bunch of community PRs merged in
>> to many plugin repos.
>>
>> Anyone have any reasons to not do a release? Anything outstanding
>> anyone wants to get merged in before moving ahead with a plugins
>> release? Any other comments on the topic?
>>
>> Cheers,
>> Fil Maj
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[DISCUSS] Plugins Release

[Filip Maj]

We did some work this week and got a bunch of community PRs merged in
to many plugin repos.

Anyone have any reasons to not do a release? Anything outstanding
anyone wants to get merged in before moving ahead with a plugins
release? Any other comments on the topic?

Cheers,
Fil Maj

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [CORE PLUGINS] Expansion of features needs to be discussed in dev@

[Filip Maj]

I know some of the plugins (all of them?) call out at the top of the
docs that they are based on standards. I think we should be more
dilligent in referencing those specs when discussing/weighing changes
to the APIs.

It would be a lot easier to maintain a stance such as "this does not
follow the spec, thus we cannot accept it" if we walked the walk and
didn't just talk the talk. By that I mean that we should put effort
in:
a) modernizing the plugins that are still valuable,
b) making the hard decisions to remove outdated plugins, and
c) blogging/documenting transition paths for consumers of plugins we
decide to get rid of

The sooner we do this the less of a burden on the project.

On Tue, Apr 25, 2017 at 2:56 PM, julio cesar sanchez
 wrote:
> Whenever I see a PR for a new feature I tell the author to send a mail to
> discuss it, most of them don't do it.
>
>
> 2017-04-25 22:22 GMT+02:00 Simon MacDonald :
>
>> Hey Shazon,
>>
>> I agree with this goal. Our plugins were based upon W3C standards as
>> they existed when the plugins were created. The standards have moved
>> on and we haven't had as much time as we would like to stay in sync. A
>> number of core plugins have been superseded by API's already available
>> in browsers (I'm looking at you, cordova-plugin-device-motion).
>>
>> Changes to any of the core plugins should align themselves with W3C
>> specs so we can increase code reuse across platforms and decrease our
>> support and maintenance costs.
>>
>>
>> Simon Mac Donald
>> http://simonmacdonald.com
>>
>>
>> On Tue, Apr 25, 2017 at 4:07 PM, Shazron  wrote:
>> > Resources are limited and we can barely keep up with all the core plugin
>> > work that needs to be done, so we have to have a process with dealing
>> with
>> > desired features that community members send out as PRs.
>> >
>> > Firstly I want to acknowledge that external contributions are valued
>> highly
>> > by the team, but they need to fulfill Cordova's goals and not be a
>> > maintenance burden on the project.
>> >
>> > GOAL:
>> > Core plugins should conform to standards whenever possible, and we should
>> > not add new features nor expand existing features without a consensus on
>> > dev@
>> >
>> > ROADMAP:
>> > I will be putting out another thread where I will propose a concrete
>> > roadmap for the existing core plugins -- listing those that will make the
>> > maintenance cut, and/or listing those that are scheduled for sunset. So
>> put
>> > your two cents there.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: cordova can't see android targets

[Filip Maj]

Hi Oleg,

This is an issue caused by Google changing the Android SDK tooling in
version 26.

If you use the latest cordova-android, it should be compatible with the new
tools. Unfortunately, support for the new tools is unreleased at this time
so you will need to use the latest cordova-android from source.

We are in the process of getting a new cordova-android release out (6.2.2)
- the vote thread just went out. 6.2.2 should support the new tools just
fine.

I believe the Cordova command line tooling can work with source
distributions of platforms. So I think if you a) clone down the
cordova-android source, b) `cd cordova-android && npm install` and c)
`cordova platform add path/to/cordova-android`, it should work.


On Apr 25, 2017 03:40, "Oleg"  wrote:

  Hi, all.

  Sorry, if i chosen the wrong list for my question, but it seems here

http://stackoverflow.com/questions/43348972/cordova-cant-see-android-targets

  nobody can help me.

  I have the next error with cordova:

~$ cordova requirements
Requirements check results for android:
Java JDK: installed 1.8.0
Android SDK: installed true
Android target: not installed
Android SDK not found. Make sure that it is installed. If it is not at
 the default location, set the ANDROID_HOME environment variable.
Gradle: installed
Error: Some of requirements check failed

But at least one android target is exist:

~$ $ANDROID_HOME/tools/bin/avdmanager list target
Available Android targets:
--
id: 1 or "android-25"
 Name: Android API 25
 Type: Platform
 API level: 25
 Revision: 3

So, i don't understand what cordova wants from me.

OS: funtoo stable
Cordova: 6.5.0
Android-studio: 162.3871768

--
Олег Неманов (Oleg Nemanov)

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Proof of Concept: Android Studio Project Structure

[Filip Maj]

Dropping ANT support now seems like a good idea.

This overall sounds good to me. One question I have is how would this
affect users that have only the command-line tools installed, and not
a full Android studio setup? Does this approach preclude those users
from leveraging Cordova? I'm not sure that's a showstopper to me, but
I would like to clarify that.

On Mon, Apr 24, 2017 at 9:30 AM, Joe Bowser  wrote:
> Hey
>
> Since we've been running into numerous issues with Google updating their
> tools already, I think it's time that we update the new project structure
> to work with Android Studio more easily so that we can integrate JUnit
> tests for plugins, Library Projects, Gradle dependencies and allow for
> people to work with Android Studio and Android tools more easily on Cordova
> projects.
>
> Right now, I have a branch where I'm currently working on stuff.  I don't
> have upgrade scripts working, nor do I have plugin installation working
> yet, but this will auto-detect the structure and will pick the right
> builder for the project.  You can check it out here.
>
> https://github.com/infil00p/cordova-android/tree/StudioProjectCleanup
>
> It should be noted that we kinda half-assed the ANT support and that we
> never properly supported Ant, so I think we should officially drop Ant
> support in the next version of Apache Cordova regardless.
>
> The big elephant in the room is the plugin installer and the fact that
> plugin authors basically abandon their projects after the 1.0 release.
> Cordova probably has the most abandonware that I've ever seen.  We're going
> to have to write a LOT of mapper code just to keep the old plugins working
> since people are using them regardless of their abandonware status, and we
> don't have the resources to re-write every plugin everywhere and support
> them.
>
> That said, we've used plugins as an excuse to not upgrade for three years
> now, and I think the problems with this position are going to get a lot
> worse the longer we pretend that Android Studio doesn't exist.
>
> Here's the TL;DR of what I propose:
> 1. Change project structure so new Cordova-Android platform directories
> have an Android Studio directory structure.
> 2. Allow for existing projects to stay the same for the time being and for
> a project upgrade to be hidden behind a flag
> 3. Move plugins to work like library projects and possibly AARs down the
> road.
>
> I know that I've written this e-mail before, but it would be great if we
> could finally move forward with this change before Google breaks more stuff
> with our current builds.
>
> Thoughts?
>
> Joe

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Cordova@7 Release

[Filip Maj]

Any specific things worth manually testing out above and beyond what
our CI does?

On Fri, Apr 21, 2017 at 6:56 PM, Shazron  wrote:
> Yes!
> I'll get on https://issues.apache.org/jira/browse/CB-12655 for the release
> (its on the board)
>
> On Fri, Apr 21, 2017 at 4:49 PM, Jesse  wrote:
>
>> Let's do it!
>>
>>
>> @purplecabbage
>> risingj.com
>>
>> On Fri, Apr 21, 2017 at 4:48 PM, Steven Gill 
>> wrote:
>>
>> > The time is nearly upon us! Next week I want to get the vote for
>> cordova@7
>> > out. We have a couple more prs I plan on merging in.
>> >
>> > I recommend folks start testing it via `npm i -g cordova@nightly`
>> >
>> > Post any links here for PRs you think should make it in.
>> >
>> > Any questions?
>> >
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] cordova-common@2.0.2 release

[Filip Maj]

none here

On Fri, Apr 14, 2017 at 7:41 PM, Shazron  wrote:
> I will start the vote tonight if there are no objections.
>
> Changes:
> Anything Mar 10 2017 and newer -
> https://github.com/apache/cordova-lib/commits/master/cordova-common
>
> This release is needed because it is blocking CB-8980 and thus
> cordova-ios@4.4.0

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [NIGHTLY BUILDS] Missing

[Filip Maj]

yay! that seemed to have fixed it!

On Tue, Mar 21, 2017 at 10:51 PM, Filip Maj <maj@gmail.com> wrote:
> Just added apachebuilds as owner to both cordova-android and cordova-ios.
>
> On Tue, Mar 21, 2017 at 8:10 PM, Darryl Pogue <dvpdin...@gmail.com> wrote:
>> Hey Vladimir,
>>
>> I noticed we were getting Jenkins build failures for the nightlies,
>> but it was correctly publishing cordova-lib and cordova nightlies to
>> npm. It's failing on cordova-android with a permissions error.
>> It looks to me like the only thing we need to do to get these working
>> is to grant publish permissions on cordova-android (and probably
>> cordova-ios) to the apachebuilds npm user?
>>
>> One of the npm owners want to give that a shot? In particular, it
>> would be nice to have nightly builds for Android while we're trying to
>> verify the new Android SDK fixes.
>>
>> ~Darryl
>>
>> On 15 February 2017 at 01:36, Vladimir Kotikov (Akvelon)
>> <v-vlk...@microsoft.com.invalid> wrote:
>>>
>>> Hey Shazron and Fil
>>>
>>> The thing with nightly builds is that they are running (or it’d better to 
>>> say they had been running until Dec, 9) on Apache infrastructure. More 
>>> specifically, this is a build job that is used to run ‘coho nightly’: 
>>> https://builds.apache.org/view/All/job/cordova-nightly
>>>
>>> There were 2 issues:
>>> 1. job was using node label that doesn’t have any nodes attached – it has 
>>> been changed by infra at the mid of November
>>> 2. NPM credentials, we were using to publish nightlies (user apachebuilds, 
>>> https://www.npmjs.com/~apachebuilds) are now incorrect, at least I’m not 
>>> able to login to NPM with these credentials.
>>>
>>> I have updated the job to run on proper set of nodes, but until we get new 
>>> credentials (or at least valid token) we’re blocked on this.
>>>
>>> -
>>> Best regards, Vladimir
>>>
>>>
>>> On 2/15/17, 03:58, "Filip Maj" <maj@gmail.com> wrote:
>>>
>>> I recall Alex saying he enabled parallel builds on cloudapp within the
>>> last week, sounds like it might be relevant. We'll need our MSFT
>>> friends and cloudapp admins to rescue us in this situation!
>>>
>>> On Tue, Feb 14, 2017 at 4:12 PM, Shazron <shaz...@apache.org> wrote:
>>> > I believe they don't run anymore. The last one was on
>>> > 2016-12-09T03:21:01.541Z
>>> >
>>> > Does anyone know what happened?
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [NIGHTLY BUILDS] Missing

[Filip Maj]

Just added apachebuilds as owner to both cordova-android and cordova-ios.

On Tue, Mar 21, 2017 at 8:10 PM, Darryl Pogue <dvpdin...@gmail.com> wrote:
> Hey Vladimir,
>
> I noticed we were getting Jenkins build failures for the nightlies,
> but it was correctly publishing cordova-lib and cordova nightlies to
> npm. It's failing on cordova-android with a permissions error.
> It looks to me like the only thing we need to do to get these working
> is to grant publish permissions on cordova-android (and probably
> cordova-ios) to the apachebuilds npm user?
>
> One of the npm owners want to give that a shot? In particular, it
> would be nice to have nightly builds for Android while we're trying to
> verify the new Android SDK fixes.
>
> ~Darryl
>
> On 15 February 2017 at 01:36, Vladimir Kotikov (Akvelon)
> <v-vlk...@microsoft.com.invalid> wrote:
>>
>> Hey Shazron and Fil
>>
>> The thing with nightly builds is that they are running (or it’d better to 
>> say they had been running until Dec, 9) on Apache infrastructure. More 
>> specifically, this is a build job that is used to run ‘coho nightly’: 
>> https://builds.apache.org/view/All/job/cordova-nightly
>>
>> There were 2 issues:
>> 1. job was using node label that doesn’t have any nodes attached – it has 
>> been changed by infra at the mid of November
>> 2. NPM credentials, we were using to publish nightlies (user apachebuilds, 
>> https://www.npmjs.com/~apachebuilds) are now incorrect, at least I’m not 
>> able to login to NPM with these credentials.
>>
>> I have updated the job to run on proper set of nodes, but until we get new 
>> credentials (or at least valid token) we’re blocked on this.
>>
>> -
>> Best regards, Vladimir
>>
>>
>> On 2/15/17, 03:58, "Filip Maj" <maj@gmail.com> wrote:
>>
>> I recall Alex saying he enabled parallel builds on cloudapp within the
>> last week, sounds like it might be relevant. We'll need our MSFT
>> friends and cloudapp admins to rescue us in this situation!
>>
>> On Tue, Feb 14, 2017 at 4:12 PM, Shazron <shaz...@apache.org> wrote:
>> > I believe they don't run anymore. The last one was on
>> > 2016-12-09T03:21:01.541Z
>> >
>> > Does anyone know what happened?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Cordova-Android 6.2.0 Release

[Filip Maj]

I am all for a new release, to get compatibiltiy with the latest SDK
tooling out ASAP. No objections here.

On Mon, Mar 20, 2017 at 12:36 PM, Joe Bowser  wrote:
> Hey
>
> Does anyone have any reason to delay Cordova-Android 6.2.0? I want to get a
> release out to address the problems people are having with the latest
> Android Tools.  There's also a multipart fix that I want to get into the
> release if possible.
>
> If there's no objections, I'll start the release process either tomorrow or
> Wednesday (when I get a desk to sit at to do this).
>
> Joe

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] plugin release : cordova-plugin-screen-orientation (attempt 2)

[Filip Maj]

I vote +1:

- Verified plugin tag 2.0.0 (6bda75f2b7) works w/ latest
cordova-android, and orientationchange event, lock and unlock
functionality works as expected on an Android emulator running Android
7.1.
- Verified plugin tag 2.0.0 (6bda75f2b7) works w/ latest cordova-ios,
and orientationchange event, lock and unlock functionality works as
expected on an iPhone 7 Plus emulator running iOS 10.2.

On Mon, Mar 20, 2017 at 4:01 AM,   wrote:
> I vote +1.
>
> * Verified signatures and hashes
> * Verified git tag
> * Verified that the plugin can be added correctly to blank app
> * Verified that blank app can be successfully built and run (windows, ios and 
> android)
> * Verified that browserified app can be successfully built and run (windows, 
> ios and android)
> * Ran smoke testing of paramedic app (windows, ios and android)
>
> Thanks,
> Alexander Sorokin
>
> -Original Message-
> From: Jesse [mailto:purplecabb...@gmail.com]
> Sent: Friday, March 17, 2017 2:40 AM
> To: dev@cordova.apache.org
> Subject: [VOTE] plugin release : cordova-plugin-screen-orientation (attempt 2)
>
> Please review and vote on the release of this plugins release by replying to 
> this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12568
>
> The plugins have been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-12568/
>
> The packages were published from their corresponding git tags:
> cordova-plugin-screen-orientation: 2.0.0 (6bda75f2b7)
>
> Upon a successful vote I will upload the archives to dist/, upload them to 
> npm, and post the corresponding blog post.
>
> Voting guidelines: https://github.com/apache/cordova-coho/blob/master/docs/
> release-voting.md
> How to vote on a plugins release at https://github.com/apache/ 
> cordova-coho/blob/master/docs/plugins-release-process.md#voting
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and subdependencies have 
> Apache-compatible licenses
> * Ensured continuous build was green when repos were tagged
>
> @purplecabbage
> risingj.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[DISCUSS] Remove cordova-android's `android_sdk_version` script

[Filip Maj]

I recently issued a pull request to update the cordova-android CLI
scripts to work with Android SDK Tools 25.3.1 [1]. As part of the
discussion in there, it came up that, in particular cases where one's
environment was not set up with proper environment variables, running
`./bin/android_sdk_version` or `./cordova/android_sdk_version` would
fail.

This script solely prints out the most-recent Android API level or
target installed on the user's machine. It is not used in any other
scripts.

I propose we remove it. I believe it is a non-standard CLI script,
that is, no other platform provides a similar script as far as I can
tell.

Thoughts?

[1] https://github.com/apache/cordova-android/pull/369

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DRAFT][REPORT] Cordova - March 2017

[Filip Maj]

+1

On Mon, Mar 13, 2017 at 9:30 PM,   wrote:
> +1
>
> Sent from my phone.
>
> ___
> Kerri Shotts
>
>> On Mar 13, 2017, at 19:43, Shazron  wrote:
>>
>> I will send this out later tonight/early tomorrow if there are no comments:
>>
>> https://github.com/cordova/apache-board-reports/blob/master/2017/2017-03.md
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[ANNOUNCEMENT] cordova-common@2.0.1 released

[Filip Maj]

cordova-common@2.0.1 is in cordova-dist and npm.

Rejoice!

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] cordova-common 2.0.1 Release

[Filip Maj]

The vote has now closed. The results are:

Positive Binding Votes: 3
Filip Maj
Alexander Sorokin
Steven Gill

The vote has passed.

On Fri, Mar 10, 2017 at 3:41 AM,  <alsoro...@apache.org> wrote:
> I vote +1.
>
> * Ran coho verify-archive
> * Verified tag
> * Verified version
> * Ability to create blank app for Windows, Android
> * Ability to build/run apps
> * Reviewed release notes
> * Verified 'cordova serve'
> * Verified that browserified app builds and runs correctly
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Friday, March 10, 2017 1:09 AM
> To: dev@cordova.apache.org
> Subject: Re: [VOTE] cordova-common 2.0.1 Release
>
> +1
>
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and subdependencies have 
> Apache-compatible licenses
> * Ran `npm test` in both `master` and `common-2.0.x` branches, for both 
> before-and-after the changes. In all four cases, tests passed.
>
> On Thu, Mar 9, 2017 at 12:49 PM, Filip Maj <maj@gmail.com> wrote:
>
>> Please review and vote on this cordova-common release by replying to
>> this email (and keep discussion on the DISCUSS thread)
>>
>> Release issue: https://issues.apache.org/jira/browse/CB-12558
>>
>> cordova-common 2.0.1 has been published to dist/dev:
>> https://dist.apache.org/repos/dist/dev/cordova/CB-12558
>>
>> The packages were published from their corresponding git tags:
>>
>> ~/src via ⬢ v6.9.4
>> ➔ coho print-tags -r common
>> Running from /Users/maj/src
>> cordova-lib: common-2.0.1 (3d6311f464)
>>
>> Upon a successful vote I will upload the archives to dist/, publish
>> them to npm. I made a call that this was a small enough release that a
>> blog post is not warranted. Feel free to respond if you disagree, and
>> I can put that together.
>>
>> Voting guidelines:
>> https://github.com/apache/cordova-coho/blob/master/docs/release-voting
>> .md
>>
>> Voting will go on for a minimum of 48 hours.
>>
>> I vote +1:
>> * Ran coho audit-license-headers over the relevant repos
>> * Ran coho check-license to ensure all dependencies and
>> subdependencies have Apache-compatible licenses
>> * Ran `npm test` in both `master` and `common-2.0.x` branches, for
>> both before-and-after the changes. In all four cases, tests passed.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[VOTE] cordova-common 2.0.1 Release

[Filip Maj]

Please review and vote on this cordova-common release by replying to
this email (and keep discussion on the DISCUSS thread)

Release issue: https://issues.apache.org/jira/browse/CB-12558

cordova-common 2.0.1 has been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/CB-12558

The packages were published from their corresponding git tags:

~/src via ⬢ v6.9.4
➔ coho print-tags -r common
Running from /Users/maj/src
cordova-lib: common-2.0.1 (3d6311f464)

Upon a successful vote I will upload the archives to dist/, publish
them to npm. I made a call that this was a small enough release that a
blog post is not warranted. Feel free to respond if you disagree, and
I can put that together.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses
* Ran `npm test` in both `master` and `common-2.0.x` branches, for
both before-and-after the changes. In all four cases, tests passed.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[DISCUSS] cordova-common patch bump + release

[Filip Maj]

I'd like to do just a patch version bump + release of cordova-common.
I recently updated the process `spawn` helper [1], which I need to
help with the Android SDK Tools 25.3.1 update that broke
cordova-android's CLI build scripts [2].

Does anyone have any reason to delay such a release? Any outstanding
patches to land?

I'd like to get this out in the next day or so so that I can land the
fixes in cordova-android shortly afterwards.

The version to be released would be cordova-common@2.0.1.

[1] https://github.com/apache/cordova-lib/pull/525
[2] https://issues.apache.org/jira/browse/CB-12554

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Mothballing cordova-blackberry

[Filip Maj]

Do we have any representatives from RIM on this list? If so would love
to hear their take.

On Fri, Mar 3, 2017 at 1:04 PM, Simon MacDonald
<simon.macdon...@gmail.com> wrote:
> +1
>
> Was talking to a blackberry dev today. They are not working on that OS ever
> again.
>
> Simon Mac Donald
> http://simonmacdonald.com
>
> On Fri, Mar 3, 2017 at 4:02 PM, Filip Maj <maj@gmail.com> wrote:
>
>> +9001
>>
>> On Fri, Mar 3, 2017 at 12:59 PM, Jesse <purplecabb...@gmail.com> wrote:
>> > +1000
>> >
>> >
>> > @purplecabbage
>> > risingj.com
>> >
>> > On Fri, Mar 3, 2017 at 12:58 PM, Shazron <shaz...@apache.org> wrote:
>> >
>> >> Effectively the project repo is dead, but let's make it official.
>> >>
>> >> Blackberry has only one new product (and the only one they will sell I
>> >> think), the upcoming BlackBerry Keyone, and it is Android 7.1 Nougat
>> based.
>> >> http://blackberrymobile.com/index.html
>> >>
>> >> I would now consider BlackBerry 10 to be legacy like the other
>> BlackBerry
>> >> OSes.
>> >>
>> >> I propose to:
>> >> 1. Close all Blackberry 10 issues in JIRA because frankly, I doubt
>> anyone
>> >> will work on them anymore
>> >> 2. Remove BlackBerry 10 from the docs (docs.cordova.io)
>> >> 3. Update the cordova-blackberry README to update the maintenance
>> status of
>> >> the repo
>> >>
>> >>
>> >> There is also the problem of our marketing on our Front Page
>> >> https://cordova.apache.org that does list BlackBerry logos and other
>> >> defunct platforms as well, which is another discussion
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Mothballing cordova-blackberry

[Filip Maj]

+9001

On Fri, Mar 3, 2017 at 12:59 PM, Jesse  wrote:
> +1000
>
>
> @purplecabbage
> risingj.com
>
> On Fri, Mar 3, 2017 at 12:58 PM, Shazron  wrote:
>
>> Effectively the project repo is dead, but let's make it official.
>>
>> Blackberry has only one new product (and the only one they will sell I
>> think), the upcoming BlackBerry Keyone, and it is Android 7.1 Nougat based.
>> http://blackberrymobile.com/index.html
>>
>> I would now consider BlackBerry 10 to be legacy like the other BlackBerry
>> OSes.
>>
>> I propose to:
>> 1. Close all Blackberry 10 issues in JIRA because frankly, I doubt anyone
>> will work on them anymore
>> 2. Remove BlackBerry 10 from the docs (docs.cordova.io)
>> 3. Update the cordova-blackberry README to update the maintenance status of
>> the repo
>>
>>
>> There is also the problem of our marketing on our Front Page
>> https://cordova.apache.org that does list BlackBerry logos and other
>> defunct platforms as well, which is another discussion
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Android] Let's drop support for Jellybean

[Filip Maj]

As much as I personally would like to do so, I wonder what the
reaction among consumers of cordova would be.

On Sun, Feb 26, 2017 at 1:39 AM, Jesse  wrote:
> +1
> Our CI tests only test as far back as 4.4, so maybe I thought we were
> already there.
>
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Fri, Feb 24, 2017 at 12:15 PM, Joe Bowser  wrote:
>
>> Hey
>>
>> Even though everything appears to be working on Jellybean, I know a lot of
>> people have been wanting to throw it to the wayside.  Normally, for us to
>> drop support for a platform, we have to wait unitl it goes below 10%, but
>> since Jellybean consists of three different API versions, and since two of
>> those are below the 5% mark, I'm tempted to just toss it by the wayside and
>> set the minimum supported version of Android to 4.4.x, or API level 19.
>>
>> How do people feel about that.  I know in the past, people were super
>> passionate about supporting everything, but given that my Android 4.1
>> device is an old Nitobi device obtained before we even became Adobe, and it
>> took five tries to get it to cooperate with adb, I'm really starting to
>> think it's time we dropped Jellybean.
>>
>> Thoughts?
>>
>> Joe
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Discuss] plugins release

[Filip Maj]

I've worked through the contacts plugin PRs, and either closed them,
pinged the authors for rebases/updates/more info, or pinged platform
maintainers for some extra eyes on ones I am unsure about.

Current state of plugin PRs:

cordova-plugin-inappbrowser --> Last week: 30, Today: 38 - it's growing!!
cordova-plugin-media --> Last week: 28, Today: 27 - woot
cordova-plugin-file-transfer --> Last week: 23, Today: 23
cordova-plugin-camera --> Last week: 22, Today: 23 - a
cordova-plugin-file --> Last week: 17, Today: 17
cordova-plugin-contacts --> Last week: 15, Today: 10 - woot
cordova-plugin-splashscreen --> Last week: 14, Today: 14
cordova-plugin-dialogs --> Last week: 14, Today: 14
cordova-plugin-media-capture --> Lsat week: 13, Today: 13
cordova-plugin-geolocation --> Last week: 12, Today: 12
cordova-plugin-battery-status --> Last week: 8, Today: 8
cordova-plugin-statusbar --> Last week: 6, Today: 5 - woot
cordova-plugin-wkwebview-engine --> Last week: 6, Today: 4 - woot
cordova-plugins --> I'm not even gonna look here
cordova-plugin-device --> Last week: 2, Today: 1 - woot
cordova-plugin-whitelist --> Last week: 2, Today: 2
cordova-plugin-vibration --> Last week: 2, Today: 1 - woot
cordova-plugin-globalization --> Last week: 1, Today: 0 - woot
cordova-plugin-screen-orientation --> Last week: 1, Today: 0 - woot
cordova-plugin-device-orientation --> Last week: 1, Today: 1
cordova-plugin-console --> Still 0
cordova-plugin-network-information --> Still 0
cordova-plugin-compat --> Still 0
cordova-plugin-legacy-whitelist --> Still 0
cordova-plugin-device-motion --> Still 0
cordova-plugin-test-framework --> Still 0

Any recommendations on which plugins I should focus on? I've been
using the plugin audit proposal [1] as a rough guide, and trying not
to focus on the ones that have warning signs of "we should get rid of
it" or "deprecate".

[1] https://github.com/cordova/cordova-discuss/pull/58/files

On Tue, Feb 14, 2017 at 5:05 PM, julio cesar sanchez
 wrote:
> I would like to get this merged
> https://github.com/apache/cordova-plugin-media/pull/124
> It's to use aac instead of amr on Android, but aac requires API 16, so I
> think we should do a major version bump
>
> 2017-02-14 23:47 GMT+01:00 Shazron :
>
>> Thanks Steve,
>> I'm focusing on wkwebview-engine plugin stuff, plus maybe a few others.
>> Here's the list of PRs outstanding, in descending order:
>>
>> cordova-plugin-inappbrowser --> 30 Pull Requests
>> cordova-plugin-media --> 28 Pull Requests
>> cordova-plugin-file-transfer --> 23 Pull Requests
>> cordova-plugin-camera --> 22 Pull Requests
>> cordova-plugin-file --> 17 Pull Requests
>> cordova-plugin-contacts --> 15 Pull Requests
>> cordova-plugin-splashscreen --> 14 Pull Requests
>> cordova-plugin-dialogs --> 14 Pull Requests
>> cordova-plugin-media-capture --> 13 Pull Requests
>> cordova-plugin-geolocation --> 12 Pull Requests
>> cordova-plugin-battery-status --> 8 Pull Requests
>> cordova-plugin-statusbar --> 6 Pull Requests
>> cordova-plugin-wkwebview-engine --> 6 Pull Requests
>> cordova-plugins --> 5 Pull Requests
>> cordova-plugin-device --> 2 Pull Requests
>> cordova-plugin-whitelist --> 2 Pull Requests
>> cordova-plugin-vibration --> 2 Pull Requests
>> cordova-plugin-globalization --> 1 Pull Requests
>> cordova-plugin-screen-orientation --> 1 Pull Requests
>> cordova-plugin-device-orientation --> 1 Pull Requests
>> cordova-plugin-console --> 0 Pull Requests
>> cordova-plugin-network-information --> 0 Pull Requests
>> cordova-plugin-compat --> 0 Pull Requests
>> cordova-plugin-legacy-whitelist --> 0 Pull Requests
>> cordova-plugin-device-motion --> 0 Pull Requests
>> cordova-plugin-test-framework --> 0 Pull Requests
>>
>> On Tue, Feb 14, 2017 at 2:02 PM, Steven Gill 
>> wrote:
>>
>> > I want to do a plugins release next week.
>> >
>> > Please share any plugin PRs you want looked at here. Would love some help
>> > reviewing and merging prs :)
>> >
>> > -Steve
>> >
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [NIGHTLY BUILDS] Missing

[Filip Maj]

I recall Alex saying he enabled parallel builds on cloudapp within the
last week, sounds like it might be relevant. We'll need our MSFT
friends and cloudapp admins to rescue us in this situation!

On Tue, Feb 14, 2017 at 4:12 PM, Shazron  wrote:
> I believe they don't run anymore. The last one was on
> 2016-12-09T03:21:01.541Z
>
> Does anyone know what happened?

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Temporary turbulence on the CI

[Filip Maj]

Holy cow! This is so awesome Alex, awesome job! I've started watching
the issue, perhaps we can make that test server more stable so we can
more effectively leverage Sauce for the testing.

On Thu, Feb 9, 2017 at 5:52 AM,   wrote:
> I think I've stabilized the builds now. Each node now has 2 executors. Each
> separate build takes longer to complete but because a lot more builds can
> now be executed in parallel, we've got ~70% performance increase overall.
>
> One thing to note though is that I moved the file transfer builds back to
> Sauce Labs emulators and disabled all tests that require a connection to a
> test server. For more information on why I did so and if you want to help or
> just track further work in this area, please refer to the following JIRA
> issue:
>
> https://issues.apache.org/jira/browse/CB-12439
>
> --Alex
>
> -Original Message-
> From: alsoro...@apache.org [mailto:alsoro...@apache.org]
> Sent: Monday, February 6, 2017 5:18 PM
> To: dev@cordova.apache.org
> Subject: Temporary turbulence on the CI
>
> Hi guys,
>
> I'm working on speeding up the Cloudapp Jenkins CI. I've enabled parallel
> job execution on the same node, so please expect some failures until I sort
> it out.
>
> Will keep you informed,
> --Alex
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: CB-11602: (android) Adds onRestart event support

[Filip Maj]

+1 !

On Wed, Jan 25, 2017 at 11:35 AM, Kerri Shotts  wrote:
> +1 to moving splash screen into platforms.
>
>
> ~ Kerri
>
>> On Jan 25, 2017, at 01:09, Simon MacDonald  wrote:
>>
>> I would be happy to see Splash Screen go back to the platforms as well.
>>
>> Simon Mac Donald
>> http://simonmacdonald.com
>>
>> On Tue, Jan 24, 2017 at 10:56 PM, Joe Bowser  wrote:
>>
>>> OK, time to address the elephant in the room:
>>>
>>> Why is the Splashscreen still a plugin?  It was only made a plugin because
>>> someone wanted to be a purist about plugins, and there's actually no good
>>> reason for it to not just be built into Cordova.  I used to think
>>> Splashscreens were dumb and were used to cover up bad loading times, but
>>> there's a good business case for them since people expect them.
>>>
>>> Also, related, Splashscreen on Android needs to be rebuilt anyway.  There's
>>> numerous bugs with it, and I think adding it back into the platforms might
>>> actually delete code and simplify things.
>>>
>>> I know that we said these exact things before at meetings and wrote them in
>>> minutes that we posted here, but I think now is probably good time to bring
>>> this up.
>>>
>>> The only reason I don't want to throw this back into Android is because I
>>> don't want crap ton of PRs in Cordova-Android just all about Splashscreen.
>>> That said, at least we can get those unit tested and actually make sure
>>> that 3 second delays are actually 3 seconds and not some random value, and
>>> other things like that.
>>>
>>>
>>> On Tue, Jan 24, 2017 at 10:47 PM, Jesse  wrote:
>>>
 I would like to see us move towards making this platform level
 functionality,  The requirements of this API happen mostly outside of the
 scope of a plugin's lifetime.

 If we could get to an api that was just, images with the right names are
 presented when the OS decides to do it, the way all native platforms
>>> work,
 I think we would be better off.


 @purplecabbage
 risingj.com

 On Fri, Jan 20, 2017 at 3:28 AM,  wrote:

> Hello,
>
> There's a related issue marked as WontFix [1][2] but as far as I
> understand it does not apply to the SplashScreen plugin as it is
> initialized on startup (via ).
> So the question is - should we add onRestart as it is not fundamentally
> different from onStart, which is supported?
> Or is there a better/more correct way to do it?
>
> [1]: https://issues.apache.org/jira/browse/CB-9620
> [2]: https://issues.apache.org/jira/browse/CB-9621
>
> Please let me know if you have any questions or considerations.
>
> Best regards,
> Sergey Shakhnazarov,
> Akvelon developer.
>
> -Original Message-
> From: Sergey Shakhnazarov [mailto:dase...@apache.org]
> Sent: Thursday, January 12, 2017 12:10
> To: dev 
> Subject: CB-11602: (android) Adds onRestart event support
>
> Hi guys,
>
> I've investigated the CB-11602 Splashscreen plugin receives onPause and
> hides [1] and realized that the splashscreen plugin currently doesn't
> handle onStop->onRestart [2] events properly.
> The reason is that we don't have the onRestart event in cordova-android
 so
> I propose to add it [3] and update the splash screen plugin code
> accordingly to handle this pause-resume events correctly [4] (i.e.
> save/restore the splashscreen state on app switch/device lock).
> Please take a look.
>
> [1]: https://na01.safelinks.protection.outlook.com/?url=https%3A%
> 2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-11602=02%
> 7C01%7Cv-seshak%40microsoft.com%7Cb58575c22fb04ad3c29308d4
> 3acabe0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636198
> 089826262946=ic0pYXcxfToH7eHWkPUktKDgm0aYMhHgfxqhJ8ECS
> sU%3D=0
> [2]:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%
> 2F%2Fdeveloper.android.com%2Freference%2Fandroid%2Fapp%
> 2FActivity.html%23onRestart=02%7C01%7Cv-seshak%
> 40microsoft.com%7Cb58575c22fb04ad3c29308d43acabe0f%7C72f988b
> f86f141af91ab2d7cd011db47%7C1%7C0%7C636198089826262946=Ido%
> 2FCxLiFO9fdJxCTb1HvIt9dBo%2BMtIjwUqo6%2FDyPaw%3D=0()
> [3]: https://na01.safelinks.protection.outlook.com/?url=https%3A%
> 2F%2Fgithub.com%2Fapache%2Fcordova-android%2Fpull%
> 2F353%2Ffiles=02%7C01%7Cv-seshak%40microsoft.com%7Cb
> 58575c22fb04ad3c29308d43acabe0f%7C72f988bf86f141af91ab2d7cd0
> 11db47%7C1%7C0%7C636198089826272954=mMHBhAcWSuBXgWOVFS
> TyX8tV8cikEKfAO4hX95A7Zcs%3D=0
> [4]: https://na01.safelinks.protection.outlook.com/?url=https%3A%
> 2F%2Fgithub.com%2Fapache%2Fcordova-plugin-splashscreen%
> 2Fpull%2F120%2Ffiles=02%7C01%7Cv-seshak%40microsoft.
> com%7Cb58575c22fb04ad3c29308d43acabe0f%7C72f988bf86f141af91a

Re: Platform Version support/coverage

[Filip Maj]

Awesome!!! Thanks so much for setting that up Alex.

Any idea on the impact this had on our test suite run times?

Now we wait for when Sauce Labs lands support for Android 6...

On Fri, Jan 20, 2017 at 8:42 AM, Alexander Sorokin (Akvelon)
<v-als...@microsoft.com> wrote:
> Hey guys,
>
> iOS 10 builds for periodic and per-PR jobs are up and running on Jenkins.
> I had some trouble with permission dialogs busting, but now everything seems 
> to be in order.
> Woo!
>
> http://cordova-ci.cloudapp.net:8080/view/Periodic%20builds/job/cordova-periodic-build/293/
>
> --Alex
>
> -Original Message-
> From: Alexander Sorokin (Akvelon) [mailto:v-als...@microsoft.com]
> Sent: Monday, January 9, 2017 1:36 PM
> To: dev@cordova.apache.org
> Subject: RE: Platform Version support/coverage
>
> I say let's do this!
>
> Going to add the iOS 10 builds this week. Will keep you informed.
>
> -Original Message-
> From: Filip Maj [mailto:maj@gmail.com]
> Sent: Friday, January 6, 2017 2:19 AM
> To: dev@cordova.apache.org
> Subject: Re: Platform Version support/coverage
>
> Thanks Shaz. If we want to make that happen, then I think that Alex will need 
> to tweak our cloudapp jenkins instance to run the ios tests against both iOS 
> 9.3 and 10. Shouldn't be too difficult, as Alex already has the 
> dual-OS-version setup in place for Android (which is how we test both 4.4 and 
> 5.1 currently).
>
> What say you, Alex?
>
> On Thu, Jan 5, 2017 at 2:58 PM, Shazron <shaz...@gmail.com> wrote:
>> For iOS, we usually test on the current iOS version and the one
>> previous, so that would be iOS 10 and iOS 9. It follows what
>> cordova-ios currently supports, which with cordova-ios@4.4.0 we would
>> increase the minimum deployment target to iOS 9 (previously discussed in a 
>> thread in this list).
>>
>> On Thu, Jan 5, 2017 at 1:01 PM, Filip Maj <maj@gmail.com> wrote:
>>
>>> Hi!
>>>
>>> TL;DR: what OS versions should we be running our tests on? What
>>> versions should we be testing against in our CI?
>>>
>>> Recently, I received an email from Sauce Labs, letting me know that
>>> support for test runs on Android 4.3 and below has officially ended.
>>> This reminded me that our current Android CI in cloudapp (which uses
>>> Sauce Labs) tests against Android 4.4 and 5.1, so we are starting to
>>> cut it pretty close with which versions of Android we are testing
>>> against.
>>>
>>> In general, I wanted to start a discussion around what OS versions of
>>> our platforms we intend to support, and which ones we would want CI
>>> coverage on?
>>>
>>> I think we probably want to have some test coverage on newer versions
>>> of Android than 5.1. Unfortunately, at this time Sauce Labs does not
>>> have support for Android 6 (let alone 7!), so our hands are tied
>>> there until Sauce catches up a bit.
>>>
>>> On iOS, cloudapp currently tests against iOS 9.3. Sauce Labs _does_
>>> have support for iOS 10, though, so we could update our CI to get
>>> that coverage if we wanted.
>>>
>>> Our CI also includes coverage for "Windows 10 Store", which, based on
>>> some CI output [1], runs on the following environment:
>>>
>>> Windows OS: installed Windows 10
>>> MSBuild Tools: installed 12.0
>>> Visual Studio: installed 14.0
>>> Windows SDK: installed 8.1
>>> Windows Phone SDK: installed 8.1
>>>
>>> What do y'all think?
>>>
>>> [1]
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcordo
>>> va-ci.cloudapp.net%3A8080%2Fview%2FPull%2520requests%2F=02%7C01%
>>> 7Cv-alsoro%40microsoft.com%7C846b538123ff473a856208d435c14103%7C72f98
>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636192551514435865=RFQsHn
>>> %2BnbajwIq6oSEfMa9Bf7mjodpl3C07HOjC%2B5R8%3D=0
>>> job/cordova-plugin-camera-pr/115/PLATFORM=windows-10-store/console
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>  B CB
> [  X  ܚX K  K[XZ[
>] ][  X  ܚX P  ܙ ݘK \ X  K ܙ B  ܈ Y  ] [ۘ[[X[ K[XZ[
>] Z [ܙ ݘK \ X  K ܙ B

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Platform Version support/coverage

[Filip Maj]

Awesome Alex!

I think we might need to do some ironing of some of the tests. iOS 10
forces a move to a newer UI automation framework (XCUITest) as opposed
to the one that's been in place until iOS 9.3 (UIAutomation). I have
made some tweaks to the Appium tests to support both, but it wouldn't
surprise me if we possibly hit some other snags.

Let me know how it goes and if I can assist with anything.

On Mon, Jan 9, 2017 at 4:36 AM, Alexander Sorokin (Akvelon)
<v-als...@microsoft.com> wrote:
> I say let's do this!
>
> Going to add the iOS 10 builds this week. Will keep you informed.
>
> -Original Message-----
> From: Filip Maj [mailto:maj@gmail.com]
> Sent: Friday, January 6, 2017 2:19 AM
> To: dev@cordova.apache.org
> Subject: Re: Platform Version support/coverage
>
> Thanks Shaz. If we want to make that happen, then I think that Alex will need 
> to tweak our cloudapp jenkins instance to run the ios tests against both iOS 
> 9.3 and 10. Shouldn't be too difficult, as Alex already has the 
> dual-OS-version setup in place for Android (which is how we test both 4.4 and 
> 5.1 currently).
>
> What say you, Alex?
>
> On Thu, Jan 5, 2017 at 2:58 PM, Shazron <shaz...@gmail.com> wrote:
>> For iOS, we usually test on the current iOS version and the one
>> previous, so that would be iOS 10 and iOS 9. It follows what
>> cordova-ios currently supports, which with cordova-ios@4.4.0 we would
>> increase the minimum deployment target to iOS 9 (previously discussed in a 
>> thread in this list).
>>
>> On Thu, Jan 5, 2017 at 1:01 PM, Filip Maj <maj@gmail.com> wrote:
>>
>>> Hi!
>>>
>>> TL;DR: what OS versions should we be running our tests on? What
>>> versions should we be testing against in our CI?
>>>
>>> Recently, I received an email from Sauce Labs, letting me know that
>>> support for test runs on Android 4.3 and below has officially ended.
>>> This reminded me that our current Android CI in cloudapp (which uses
>>> Sauce Labs) tests against Android 4.4 and 5.1, so we are starting to
>>> cut it pretty close with which versions of Android we are testing
>>> against.
>>>
>>> In general, I wanted to start a discussion around what OS versions of
>>> our platforms we intend to support, and which ones we would want CI
>>> coverage on?
>>>
>>> I think we probably want to have some test coverage on newer versions
>>> of Android than 5.1. Unfortunately, at this time Sauce Labs does not
>>> have support for Android 6 (let alone 7!), so our hands are tied
>>> there until Sauce catches up a bit.
>>>
>>> On iOS, cloudapp currently tests against iOS 9.3. Sauce Labs _does_
>>> have support for iOS 10, though, so we could update our CI to get
>>> that coverage if we wanted.
>>>
>>> Our CI also includes coverage for "Windows 10 Store", which, based on
>>> some CI output [1], runs on the following environment:
>>>
>>> Windows OS: installed Windows 10
>>> MSBuild Tools: installed 12.0
>>> Visual Studio: installed 14.0
>>> Windows SDK: installed 8.1
>>> Windows Phone SDK: installed 8.1
>>>
>>> What do y'all think?
>>>
>>> [1]
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcordo
>>> va-ci.cloudapp.net%3A8080%2Fview%2FPull%2520requests%2F=02%7C01%
>>> 7Cv-alsoro%40microsoft.com%7C846b538123ff473a856208d435c14103%7C72f98
>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636192551514435865=RFQsHn
>>> %2BnbajwIq6oSEfMa9Bf7mjodpl3C07HOjC%2B5R8%3D=0
>>> job/cordova-plugin-camera-pr/115/PLATFORM=windows-10-store/console
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Platform Version support/coverage

[Filip Maj]

Thanks Shaz. If we want to make that happen, then I think that Alex
will need to tweak our cloudapp jenkins instance to run the ios tests
against both iOS 9.3 and 10. Shouldn't be too difficult, as Alex
already has the dual-OS-version setup in place for Android (which is
how we test both 4.4 and 5.1 currently).

What say you, Alex?

On Thu, Jan 5, 2017 at 2:58 PM, Shazron <shaz...@gmail.com> wrote:
> For iOS, we usually test on the current iOS version and the one previous,
> so that would be iOS 10 and iOS 9. It follows what cordova-ios currently
> supports, which with cordova-ios@4.4.0 we would increase the minimum
> deployment target to iOS 9 (previously discussed in a thread in this list).
>
> On Thu, Jan 5, 2017 at 1:01 PM, Filip Maj <maj@gmail.com> wrote:
>
>> Hi!
>>
>> TL;DR: what OS versions should we be running our tests on? What
>> versions should we be testing against in our CI?
>>
>> Recently, I received an email from Sauce Labs, letting me know that
>> support for test runs on Android 4.3 and below has officially ended.
>> This reminded me that our current Android CI in cloudapp (which uses
>> Sauce Labs) tests against Android 4.4 and 5.1, so we are starting to
>> cut it pretty close with which versions of Android we are testing
>> against.
>>
>> In general, I wanted to start a discussion around what OS versions of
>> our platforms we intend to support, and which ones we would want CI
>> coverage on?
>>
>> I think we probably want to have some test coverage on newer versions
>> of Android than 5.1. Unfortunately, at this time Sauce Labs does not
>> have support for Android 6 (let alone 7!), so our hands are tied there
>> until Sauce catches up a bit.
>>
>> On iOS, cloudapp currently tests against iOS 9.3. Sauce Labs _does_
>> have support for iOS 10, though, so we could update our CI to get that
>> coverage if we wanted.
>>
>> Our CI also includes coverage for "Windows 10 Store", which, based on
>> some CI output [1], runs on the following environment:
>>
>> Windows OS: installed Windows 10
>> MSBuild Tools: installed 12.0
>> Visual Studio: installed 14.0
>> Windows SDK: installed 8.1
>> Windows Phone SDK: installed 8.1
>>
>> What do y'all think?
>>
>> [1] http://cordova-ci.cloudapp.net:8080/view/Pull%20requests/
>> job/cordova-plugin-camera-pr/115/PLATFORM=windows-10-store/console
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Platform Version support/coverage

[Filip Maj]

Hi!

TL;DR: what OS versions should we be running our tests on? What
versions should we be testing against in our CI?

Recently, I received an email from Sauce Labs, letting me know that
support for test runs on Android 4.3 and below has officially ended.
This reminded me that our current Android CI in cloudapp (which uses
Sauce Labs) tests against Android 4.4 and 5.1, so we are starting to
cut it pretty close with which versions of Android we are testing
against.

In general, I wanted to start a discussion around what OS versions of
our platforms we intend to support, and which ones we would want CI
coverage on?

I think we probably want to have some test coverage on newer versions
of Android than 5.1. Unfortunately, at this time Sauce Labs does not
have support for Android 6 (let alone 7!), so our hands are tied there
until Sauce catches up a bit.

On iOS, cloudapp currently tests against iOS 9.3. Sauce Labs _does_
have support for iOS 10, though, so we could update our CI to get that
coverage if we wanted.

Our CI also includes coverage for "Windows 10 Store", which, based on
some CI output [1], runs on the following environment:

Windows OS: installed Windows 10
MSBuild Tools: installed 12.0
Visual Studio: installed 14.0
Windows SDK: installed 8.1
Windows Phone SDK: installed 8.1

What do y'all think?

[1] 
http://cordova-ci.cloudapp.net:8080/view/Pull%20requests/job/cordova-plugin-camera-pr/115/PLATFORM=windows-10-store/console

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: plugins and engines

[Filip Maj]

What about a new flag, --ignore-engines or something, instead of
changing an existing flag? Who knows what users rely on the existing
--force functionality?

On Thu, Jan 5, 2017 at 11:54 AM, Shazron <shaz...@gmail.com> wrote:
> You're right, --force does exist but the help for it says "forces copying
> source files from the plugin even if the
> same file already exists in the target directory" which is different
> conceptually from the force we want, in that we want to ignore engine
> restrictions.
>
> We could overload --force to do that as well I suppose?
>
> On Thu, Jan 5, 2017 at 9:17 AM, Steven Gill <stevengil...@gmail.com> wrote:
>
>> I think `--force` does exist and work for plugin add
>>
>> On Wed, Jan 4, 2017 at 11:22 PM, Shazron <shaz...@gmail.com> wrote:
>>
>> > Forgot about that merged proposal. What's lacking here is I think, a way
>> > for the user to override the engine version enforcement (for whatever
>> > reason, buggy CLI or plugin.xml, or they know something we don't know),
>> > something like a --force-install or something to that effect.
>> >
>> > On Wed, Jan 4, 2017 at 11:13 PM, Joe Bowser <bows...@gmail.com> wrote:
>> >
>> > > First of all, do we even suggest that the plugins will work to begin
>> > with,
>> > > or do we just not prevent people from installing plugins and tell them
>> > that
>> > > it may or may not work or that it's not supported when it fails?  I'm
>> > very
>> > > much with the latter, because while we don't test things we don't
>> > support,
>> > > some people are still using Ant for builds and some people are still
>> > > running the latest version of Cordova on Gingerbread, and while I think
>> > > people shouldn't be doing these things for very obvious reasons, I
>> don't
>> > > want to prevent them from doing it.
>> > >
>> > > Right now we only guarantee that the plugins released work on the most
>> > > recent version of Cordova that's released at any time.  We only do
>> > > backwards-compatibility only because people ask for it (or complain
>> very
>> > > loudly when we break it).  We don't do any testing of this past a
>> simple
>> > > spot check because we don't test plugins with prior versions of
>> > Cordova.  I
>> > > think that we really need to figure out what we do support.  We should
>> > > really stick to our six month deprecation policy on platform support
>> > unless
>> > > people want to step up and find the resources for all the CI work that
>> > > would be required.
>> > >
>> > > Basically, while I don't want to support earlier versions of Cordova, I
>> > > don't want to prevent people from using it either with an engine tag
>> > unless
>> > > there's some security thing or some blatantly obvious piece of
>> > > functionality that's required like in Camera.  (Shouldn't
>> > > cordova-plugin-compat fix the compile problems on Android 4.1.1, or is
>> > this
>> > > a thing where you just bump the API level?)
>> > >
>> > > On Wed, Jan 4, 2017 at 8:21 AM, julio cesar sanchez <
>> > > jcesarmob...@gmail.com>
>> > > wrote:
>> > >
>> > > > I think we should start testing plugins with cordova-android 4.1.1 as
>> > is
>> > > > the lower required by Google to publish on Google play. If some
>> plugin
>> > > > doesn't compile then increase the engine version to next
>> > cordova-android.
>> > > > In example, camera plugin doesn't compile with cordova-android 4.1.1.
>> > > >
>> > > > For cordova-ios we should require at least 3.4.1 as is the version
>> that
>> > > > included the 64bit support, required by apple, not sure if they
>> > require a
>> > > > newer version for some other reason now.
>> > > >
>> > > >
>> > > > El 4 ene. 2017 2:52 p. m., "Filip Maj" <maj@gmail.com> escribió:
>> > > >
>> > > > > Sounds like a good idea, but how to go about doing it? We probably
>> > > > > can't easily, for example, rule out older versions of iOS without
>> > > > > someone testing with an old Xcode version.
>> > > > >
>> > > > > On Tue, Jan 3, 2017 at 5:15 PM, Shazron <shaz...@gmail.com> wrote:
>> > > > > > Relate

Re: [Vote] 6.1.1 Android Release

[Filip Maj]

I vote +1:
 - nightly CI builds for cordova-android have two failures, but they
are both "connection broken" ones. (cc @alsorokin). otherwise looks
good. I attribute this to a CI server hiccup:
* 
http://cordova-ci.cloudapp.net:8080/view/Periodic%20builds/job/cordova-periodic-build/PLATFORM=android-5.1,PLUGIN=cordova-plugin-globalization/279/console
* 
http://cordova-ci.cloudapp.net:8080/view/Periodic%20builds/job/cordova-periodic-build/PLATFORM=android-4.4,PLUGIN=cordova-plugin-battery-status/279/console
 - created a mobilespec app using the createmobilespec.js helper via
`./cordova-mobile-spec/createmobilespec/createmobilespec.js --android
--variable 
"FILETRANSFER_SERVER_ADDRESS=\"http://evening-reaches-13417.herokuapp.com\""`
(with cordova-android using the 6.1.1 tag, and prod-released plugins).
looks good, tested on a Pixel running Android 7.1.1
 - created a hello world app using the cli via `cordova platform add
../cordova-android` and ran it just fine on Pixel running Android
7.1.1.
 - tested ./bin/create script and its generated ./cordova/build and
./cordova/run scripts. once again: works fine on a Pixel w/ Android
7.1.1


On Wed, Jan 4, 2017 at 11:47 AM, Karen Tran  wrote:
> I vote +1:
> * Created and ran a plain app
> * Ran app from Android Studio
> * Ran mobilespec
>
> On Tue, Jan 3, 2017 at 9:03 PM, Steven Gill  wrote:
>
>> Please review and vote on this 6.1.1 Android Release
>> by replying to this email (and keep discussion on the DISCUSS thread)
>>
>> Release issue: https://issues.apache.org/jira/browse/CB-12314
>>
>> The archive has been published to
>> dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12314
>>
>>
>> The package was published from its corresponding git tag:
>> cordova-android: 6.1.1 (96457effbc)
>>
>> Note that you can test it out via:
>>
>> cordova platform add https://github.com/apache/cordova-android#6.1.1
>>
>> Upon a successful vote I will upload the archive to dist/, publish it
>> to npm, and post the blog post.
>>
>> Voting guidelines:
>> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>>
>> Voting will go on for a minimum of 48 hours.
>>
>> I vote +1:
>> * Ran coho audit-license-headers over the relevant repos
>> * Ran coho check-license to ensure all dependencies and
>> subdependencies have Apache-compatible licenses
>> * Ran mobilespec
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: plugins and engines

[Filip Maj]

Sounds like a good idea, but how to go about doing it? We probably
can't easily, for example, rule out older versions of iOS without
someone testing with an old Xcode version.

On Tue, Jan 3, 2017 at 5:15 PM, Shazron  wrote:
> Related: https://issues.apache.org/jira/browse/CB-6582
> (almost 3 years old...)
>
> TLDR; we should update the engine tags, with as much granularity as
> possible.
>
> I think we didn't do this because we don't actually know if it *doesn't*
> work on an older version (since of course we don't test the current version
> with older platform version) and didn't want to unnecessarily restrict a
> user from installing it.
>
> We planned to pin core plugins to a cordova-lib version but we decided to
> use engine tags in plugins:
> https://github.com/cordova/cordova-discuss/blob/master/proposals/pinningAndVersioning.md
>
>
> On Tue, Jan 3, 2017 at 12:26 PM, julio cesar sanchez > wrote:
>
>> I have noticed that most of the plugins don't use the engine tags or have
>> them set to cordova 3.0.0 or 3.1.0 which are very old.
>>
>> As we drop support for old iOS/Android versions when updating cordova-ios
>> and cordova-android, what is our policy for iOS/Android versions support in
>> plugins?
>>
>> Right now people can use the plugins on very old versions of iOS or Android
>> despite we don't support them on the platforms, as the plugins engines are
>> set to 3.0.0 or 3.1.0 on most of them.
>>
>> Should we start updating the engines to newer cordova versions? or even
>> fine grain it to cordova-ios/cordova-android versions?
>> I have noticed that we even have engines for iOS versions using apple-ios
>> on the engine tag
>> https://github.com/apache/cordova-plugin-wkwebview-
>> engine/blob/master/plugin.xml#L35
>> (but not sure if this really does something as the plugin can be
>> installed/used in older iOS versions and what works or doesn't work is
>> controlled in the code)
>>
>> Or just say that the old Android/iOS version is not supported by Cordova
>> anymore if someone complains about a plugin not working?
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] Plugins Release (Dec 12th 2016)

[Filip Maj]

I vote +1:
 - successfully created android and ios projects with the plugins
 - ran through the manual tests for both plugins on Android 5.1 and
iOS 9.3 emusims.

On Thu, Dec 15, 2016 at 2:13 AM,   wrote:
> I vote +1
>
> * Verified signatures and hashes
> * Verified tags
> * Verified that plugins can be added correctly to blank app
> * Verified that blank app can be successfully built and ran (windows, ios and 
> android)
> * Verified that browserified app can be successfully built and ran (windows, 
> ios and android)
> * Ran smoke testing of paramedic app (windows, ios and android)
>
> -Original Message-
> From: Shazron [mailto:shaz...@apache.org]
> Sent: Wednesday, December 14, 2016 11:35 PM
> To: dev@cordova.apache.org
> Subject: [VOTE] Plugins Release (Dec 12th 2016)
>
> Please review and vote on the release of this plugins release by replying to 
> this email (and keep discussion on the DISCUSS thread)
>
> Release issue: 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-12237=02%7C01%7Cv-alsoro%40microsoft.com%7C0aad75fd82434a2f2fa008d42460cc10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636173445531475387=dXJxLumDRghnCq3LfybY3ru%2ByIe2t%2FTlWthNDn2IHkU%3D=0
>
> The plugins have been published to dist/dev:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fcordova%2FCB-12237%2F=02%7C01%7Cv-alsoro%40microsoft.com%7C0aad75fd82434a2f2fa008d42460cc10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636173445531475387=JnMywcZKS1gAGjNeJ%2BeEEktHPxDD6tmZuR9hc4l938Q%3D=0
>
> The packages were published from their corresponding git tags:
> cordova-plugin-inappbrowser: 1.6.1 (b6e575be32)
> cordova-plugin-battery-status: 1.2.2 (ee2388710d)
>
> Upon a successful vote I will upload the archives to dist/, upload them to 
> npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-coho%2Fblob%2Fmaster%2Fdocs%2Frelease-voting.md=02%7C01%7Cv-alsoro%40microsoft.com%7C0aad75fd82434a2f2fa008d42460cc10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636173445531475387=yqsclPrWPStZ49EH4QeY88ULbU7sLmLPFCgOm3h%2BC8U%3D=0
>
> How to vote on a plugins release at
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-coho%2Fblob%2Fmaster%2Fdocs%2Fplugins-release-process.md%23voting=02%7C01%7Cv-alsoro%40microsoft.com%7C0aad75fd82434a2f2fa008d42460cc10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636173445531475387=L%2BvUXLPr9qWtslHcjQDKnUMP2pnNw0R0%2FXqsRl%2F9b%2Fs%3D=0
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and subdependencies have 
> Apache-compatible licenses
> * Ensured continuous build was green when repos were tagged
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Plugins Release Dec 12th, 2016

[Filip Maj]

+1

On Wed, Dec 14, 2016 at 12:19 PM, julio cesar sanchez
 wrote:
> +1
>
> 2016-12-14 20:01 GMT+01:00 Shazron :
>
>> Two plugins that were omitted from the last released are planned for this
>> one:
>> 1) Updates in cordova-plugin-battery-status that we discussed (--browserify
>> fixes for Windows)
>> 2) The package.json update in cordova-plugin-inappbrowser (same version,
>> 1.6.0)
>>
>> cordova-plugin-screen-orientation release has been postponed for the next
>> one.
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DRAFT] [REPORT] Cordova - December 2016

[Filip Maj]

LGTM

On Tue, Dec 13, 2016 at 5:11 PM, Shazron  wrote:
> I will send this out later tonight/early tomorrow if there are no comments:
>
> https://github.com/cordova/apache-board-reports/blob/master/2016/2016-12.md

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] EOL cordova-medic

[Filip Maj]

On Mon, Dec 12, 2016 at 1:46 PM, Jesse  wrote:
> What would be the added responsibilities for cordova-paramedic?

Good question. As far as I can tell, I believe paramedic would need to
additionally house the helper JSON files containing configuration that
one passes into paramedic - basically replacing the various flags one
can run paramedic with with a single one pointing to a file instead.

In particular, the Jenkins configs that the cloudapp CI uses that it
feeds into paramedic [1] - including the "local" ones used for local
testing [2], which seem particularly relevant to paramedic's mission.
This would save our Jenkins instance from pulling the medic repo down,
speeding up test execution (it seems silly to clone a whole repo just
to pull a few JSON files out!).

So right now, when I want to run paramedic locally, I invoke something like:

$ node cordova-paramedic/main.js --platform android --plugin
./cordova-plugin-contacts --verbose --cleanUpAfterRun

I can reduce on the flags passed in by pointing paramedic to the
afore-mentioned local configs, but, these currently exist in the medic
repo. So I've actually been running paramedic recently like so:

$ node cordova-paramedic/main.js --plugin
./cordova-plugin-contacts --config
./cordova-medic/jenkins-conf/pr/local/android-5.1.config.json

The above incantation is also how our cloudapp CI invokes paramedic:
by pointing it to a config file (it points it to a "non-local" config
file, e.g. [3]).

In effect, it is just shuffling around code from one repo to the
other, but the benefits we get are:
 - save compute within our CI
 - all testing-relevant configurations will exist in one repo, not two
 - we can remove the medic repo along with its code duplication of paramedic

The cons, as far as I can tell, are:
 - there will be a new 'config' top-level directory

Let me know how that sounds and what else I've missed.

[1] https://github.com/apache/cordova-medic/tree/master/jenkins-conf
[2] https://github.com/apache/cordova-medic/tree/master/jenkins-conf/pr/local
[3] 
https://github.com/apache/cordova-medic/blob/master/jenkins-conf/pr/android-5.1.config.json

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[DISCUSS] EOL cordova-medic

[Filip Maj]

Dearest cordova devs,

I'd like to discuss the possibility of killing off the cordova-medic
repo. Kinda funny, as I landed the first commit in that repo over 4
years ago.

I recently sent some updates in a pull request to medic [1], updating
some appium stuff, and after some discussion with Alex, he pointed out
that medic is pretty much not used these days. With paramedic taking
over as both the local testing tool as well as the keystone piece for
Cordova's CI on cloudapp, I don't think it is worth maintaining two
similar repositories with lots of code duplication between them.

It looks to me like Apache's buildbot configs for Cordova exist in the
medic repo. How valuable are these? Worth keeping around? Is execution
on Apache buildbot going to be a thing once more in the future?
Cloudapp seems to be doing an excellent job for us on its own...

Other than the buildbot configs, I believe the only thing that needs
to be migrated out are the Jenkins configs. This would be a beneficial
move for our CI system anyways, as right now every single Jenkins job
pulls down the medic repo _solely to get the Jenkins configs_. Moving
the Jenkins configs into the paramedic repo would save every cloudapp
job a repo pull, saving some time, and in CI, every second counts :)

Anything else I'm missing? What do y'all think? Good idea? Bad idea?

Thanks for your feedback!

-Fil

[1] https://github.com/apache/cordova-medic/pull/106

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [BLOG POST] Dec 07 2016 Plugins Release

[Filip Maj]

+1

On Mon, Dec 12, 2016 at 11:19 AM, Kerri Shotts  wrote:
> +1
>
> ~ Kerri
>
>> On Dec 11, 2016, at 17:17, Shazron  wrote:
>>
>> https://github.com/apache/cordova-docs/pull/667
>>
>> +1 it, etc
>>
>> Pending npm package publish.
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] Plugins Release

[Filip Maj]

I vote +1:
 - created a cordova-android 6.1.0-based mobile-spec project,
installed relevant tags of plugins, ran autotests, poked around manual
tests, things seem fine.
 - created a cordova-ios 4.3.1-based mobile-spec project, installed
relevant tags of plugins, ran autotests, poked around manual tests,
things seem fine.

On Wed, Dec 7, 2016 at 5:26 PM, Shazron  wrote:
> Please review and vote on the release of this plugins release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12224
>
> The plugins have been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-12224/
>
> The packages were published from their corresponding git tags:
> cordova-plugin-battery-status: 1.2.1 (59189285b6)
> cordova-plugin-camera: 2.3.1 (9eba35e2f6)
> cordova-plugin-console: 1.0.5 (8bf1ba18d5)
> cordova-plugin-contacts: 2.2.1 (af620d6cde)
> cordova-plugin-device: 1.1.4 (a736ae44b1)
> cordova-plugin-device-motion: 1.2.3 (5e0e28f4f2)
> cordova-plugin-device-orientation: 1.0.5 (4b5ead9000)
> cordova-plugin-dialogs: 1.3.1 (233aff26f8)
> cordova-plugin-file: 4.3.1 (db39e7ccab)
> cordova-plugin-file-transfer: 1.6.1 (aee45754a9)
> cordova-plugin-geolocation: 2.4.1 (7934ed7026)
> cordova-plugin-globalization: 1.0.5 (594651d272)
> cordova-plugin-inappbrowser: 1.6.0 (009e662c82)
> cordova-plugin-legacy-whitelist: 1.1.2 (7c561bdff1)
> cordova-plugin-media: 2.4.1 (f0a6d45120)
> cordova-plugin-media-capture: 1.4.1 (b09b24d71b)
> cordova-plugin-network-information: 1.3.1 (0079edbaa5)
> cordova-plugin-screen-orientation: 1.4.2 (fff9124669)
> cordova-plugin-splashscreen: 4.0.1 (782939f7ef)
> cordova-plugin-statusbar: 2.2.1 (a50208bda2)
> cordova-plugin-test-framework: 1.1.4 (1a9d5cd241)
> cordova-plugin-vibration: 2.1.3 (fcc6f19a08)
> cordova-plugin-whitelist: 1.3.1 (79f74a00e2)
> cordova-plugin-wkwebview-engine: 1.1.1 (91e9d74e78)
>
> Upon a successful vote I will upload the archives to dist/, upload them to
> npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> How to vote on a plugins release at
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and subdependencies
> have Apache-compatible licenses
> * Ensured continuous build was green when repos were tagged

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: An idea for manually testing plugins

[Filip Maj]

As Alex Sorokin kindly pointed out to me on Slack, we have Appium UI
automation already existing for the contacts [1] and camera [2]
plugins. Our CI system also executes on this to automate the UI
end-to-end and guard against further errors [3]. The CI tosses this
job over to Sauce Labs to do the heavy lifting: Sauce runs the test
[4] from the example from [3], and, based on the logs, looks to
execute all that fun web + native context UI automation -
unfortunately Sauce only stores assets around for a month, so we can't
see the video or screenshots (it's been over a month since the last
contacts PR).

But all that's to say that, with that in place, I think it's mostly a
matter of applying this approach to other plugins. I think the value
of the UI automation-based tests is wa higher than the autotests;
asserting that a JavaScript function exists inside the Cordova webview
is a good sanity check, but asserting that you can pick a contact via
a native UI and have the relevant contact details show up back in the
Cordova webview, in my opinion, is a much more thorough test of the
functions of the plugin APIs.

Lastly, I think documenting how to set up UI automation tests such as
the ones in the camera and contacts plugins in the
cordova-plugin-test-framework readme makes sense.

Let me know what y'all think.

[1] https://github.com/apache/cordova-plugin-contacts/blob/master/appium-tests
[2] https://github.com/apache/cordova-plugin-camera/blob/master/appium-tests
[3] 
http://cordova-ci.cloudapp.net:8080/view/Pull%20requests/job/cordova-plugin-contacts-pr/lastSuccessfulBuild/PLATFORM=ios/consoleText
[4] https://saucelabs.com/beta/tests/b014505bd8894ff58b383471bdaf4759

On Wed, Dec 7, 2016 at 6:14 AM, Filip Maj <maj@gmail.com> wrote:
> I am planning on putting a proof of concept together for a few plugins, and
> having something like mobile spec be able to string multiple plugins' UI
> automation tests together and assert pass/failure (via its defineAutoTests /
> defineManualTests-like functions).
>
> I'll post more when I have something to show :)
>
> The idea would then be to help guide how to do this kind of testing via the
> framework Cordova has built up for plugin testing via the
> cordova-plugin-test-framework plugin.
>
> On Dec 7, 2016 05:56, "julio cesar sanchez" <jcesarmob...@gmail.com> wrote:
>>
>> I was the other way around, I got Appium working easily, but I was never
>> able to make calabash work in iOS because it always failed to instrument
>> my
>> app.
>> Both worked fine for Android though.
>>
>>
>> 2016-12-07 12:48 GMT+01:00 Trevor Brindle <tabrin...@gmail.com>:
>>
>> > As little market share as windows has, it's hard to say how much effort
>> > should be dedicated to additional testing for it. That said, if windows
>> > testing is deemed necessary, I don't think we have much choice.
>> >
>> > Just keep in mind the new windows support and new iOS driver are all
>> > appium
>> > 1.6, only released less than 60 days ago.
>> >
>> > Perhaps a PoC project should be done for picking the appropriate
>> > technology?
>> >
>> > We are midway through a similar PoC at my place of work, I could
>> > volunteer
>> > some time.
>> >
>> > On Tue, Dec 6, 2016 at 10:02 PM Filip Maj <maj@gmail.com> wrote:
>> >
>> > > Full disclosure: I contribute(d) to appium and worked for Sauce Labs,
>> > >
>> > > so I am pretty biased ;)
>> > >
>> > >
>> > >
>> > > Calabash, unfortunately, is iOS and Android only and does not support
>> > >
>> > > Windows app, whereas Appium does via WinAppDriver [1].
>> > >
>> > >
>> > >
>> > > I agree that appium, at least earlier on, was difficult to set up.
>> > >
>> > > These days it's a simple `npm install`. I think appium has a much more
>> > >
>> > > prolific committership to boot (MSFT contributes to it, for example).
>> > >
>> > > The github network stats for each project back that up as well.
>> > >
>> > >
>> > >
>> > > [1] https://github.com/microsoft/winappdriver
>> > >
>> > >
>> > >
>> > > On Tue, Dec 6, 2016 at 4:02 PM, Trevor Brindle <tabrin...@gmail.com>
>> > > wrote:
>> > >
>> > > > In my experience with appium, it is troublesome to set up and
>> > > > maintain.
>> > > We
>> > >
>> > > > may investigate other frameworks that have similar functionality. I
>> >

Re: An idea for manually testing plugins

[Filip Maj]

Full disclosure: I contribute(d) to appium and worked for Sauce Labs,
so I am pretty biased ;)

Calabash, unfortunately, is iOS and Android only and does not support
Windows app, whereas Appium does via WinAppDriver [1].

I agree that appium, at least earlier on, was difficult to set up.
These days it's a simple `npm install`. I think appium has a much more
prolific committership to boot (MSFT contributes to it, for example).
The github network stats for each project back that up as well.

[1] https://github.com/microsoft/winappdriver

On Tue, Dec 6, 2016 at 4:02 PM, Trevor Brindle <tabrin...@gmail.com> wrote:
> In my experience with appium, it is troublesome to set up and maintain. We
> may investigate other frameworks that have similar functionality. I have
> had great luck with calabash.
>
>
> On Tue, Dec 6, 2016 at 5:30 PM julio cesar sanchez <jcesarmob...@gmail.com>
> wrote:
>
>> +1 to appium
>>
>>
>>
>> 2016-12-05 23:33 GMT+01:00 Filip Maj <maj@gmail.com>:
>>
>>
>>
>> > Hi, it's me again!
>>
>> >
>>
>> > How I'd like to contribute to Cordova is to help automate the stuff
>>
>> > that saves committers having to take the manual time to do themselves.
>>
>> > I think a good first goal would be to help automate as much of
>>
>> > platform release testing as possible [1]. The autotests seem to be
>>
>> > handled relatively well by the CI system so far (if anyone feels this
>>
>> > is not true, please speak up! I want to hear about what works and what
>>
>> > does not). The other part of mobile-spec-based platform release
>>
>> > testing is to "run the manual tests". After reading the
>>
>> > cordova-plugin-test-framework README [2], I thought this would be a
>>
>> > good place to give plugin developers some better tools to deal with
>>
>> > testing complex UI interactions that the autotests can't handle on
>>
>> > their own. I was thinking appium [3] would be a good tool to
>>
>> > complement that in this case. It gives us UI hooks into both web and
>>
>> > natives contexts within hybrid applications, plus it also allows us to
>>
>> > inject JavaScript into the web context. Wondering what others think?
>>
>> >
>>
>> > I could then foresee, with a little bit of scaffolding, a way to
>>
>> > string plugins' appium tests together to fully automate the 'manual'
>>
>> > testing of plugin tests during platform release testing.
>>
>> >
>>
>> > Let me know what y'all think!
>>
>> >
>>
>> > [1] https://github.com/apache/cordova-coho/blob/master/docs/
>>
>> > platforms-release-process.md#what-to-test
>>
>> > [2] https://github.com/apache/cordova-plugin-test-framework#
>>
>> > defining-manual-tests
>>
>> > [3] appium.io
>>
>> >
>>
>> > -
>>
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>> >
>>
>> >
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Access to Jenkins instance, questions about CI

[Filip Maj]

Thanks Alexander!

I seem to have config access to the jobs now, which is what I needed.
Thank you :) It looks like your email will be notified on
configuration changes, so if I mess something up, you will know pretty
quickly who did it :D

I will take a look at issue #2 to start :)

As for [3], yeah, if I don't have access to the infrastructure, tough
for me to try to fix anything :D. Some level of public monitoring
would be helpful, at least to alert the rest of the committers to an
infrastructure problem, but drilling into CI execution log output also
reveals the infrastructure problem quickly, so perhaps it is not
needed.

On Tue, Dec 6, 2016 at 2:09 AM, Alexander Sorokin (Akvelon)
<v-als...@microsoft.com> wrote:
> Hey Filip.
>
> I've granted you the permissions you need for the cloudapp Jenkins. You'll 
> just need to log in with your "filmaj" Github account.
> Use your new powers well, because while trying to give them to you I've 
> almost messed up all the permissions settings on the CI :)
>
> Regarding your findings:
> Your [1] link points to *-test job, these jobs are only meant to test things 
> like new paramedic code before it gets into master and generally live for a 
> couple of days, then get deleted (if I don't forget to do so).
> This particular one is meant to test my upcoming fix for paramedic to 
> properly handle the app uninstall timeout and the phantom failures we now get 
> for windows phone 8.1 builds.
>
> Your [2] link seems like a "cordova-coho npm-link" issue which needs to be 
> investigated. It doesn't look like it's breaking things so it's not a high 
> priority (for me) right now.
>
> [3]: When a node goes offline, "CI Sentinels" ™ get a notification via email, 
> right now that would be me, Vladimir Kotikov and Sergey Shakhnazarov. If 
> you'd like to be included to the caste, just let me know - but since the 
> slave machines are inside Microsoft infrastructure it is only us who have the 
> access to both of them and it is only us who can bring the slave back online 
> if something bad happens.
>
> Thanks,
> Alexander Sorokin
>
> -Original Message-
> From: Filip Maj [mailto:maj@gmail.com]
> Sent: Tuesday, December 6, 2016 1:32 AM
> To: dev@cordova.apache.org
> Subject: Access to Jenkins instance, questions about CI
>
> Dearest Cordova devs,
>
> I would like to get admin-level access to the cloudapp jenkins
> instance: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcordova-ci.cloudapp.net%3A8080%2F=02%7C01%7Cv-alsoro%40microsoft.com%7C9ab9ec2d342a40ee3aee08d41d5e8c4d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636165739303098482=pdUokGPtsLwPvq6SynMtUlRt5iTOn2yY8S0SlA%2FCKio%3D=0
>
> Who can grant me this karma?
>
> I wanted to check out how the various jobs are configured, what triggers them 
> and what the triggered code looks like.
>
> I also wanted to fix some things I've noticed:
>  - File Transfer tests relying on Alex Sorokin's fork of paramedic, which now 
> seems to be gone, and thus fails the job [1]
>  - I noticed some popd/pushd errors in the periodic builds for specific 
> plugins, as well as npm error output [2]. Seems to be related to a missing 
> cordova-create directory or something.
>
> Had some followup questions too!
>  - When a worker node goes down or becomes inaccessible, that may fail a 
> build. (see e.g. the Mac node graphs [3]). When this happens, do we get 
> alerted? And how would do we fix it?
>  - In the Periodic Builds section [4], what is the difference between the 
> "build" [5] and the "test" [6] jobs? The test jobs seem to only care about 
> network information and file transfer plugins, but other than that, I'm 
> wondering what the vision here is?
>
> [1] 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcordova-ci.cloudapp.net%3A8080%2Fview%2FPeriodic%2520builds%2Fjob%2Fcordova-periodic-test%2FPLATFORM%3Dandroid-4.4%2CPLUGIN%3Dcordova-plugin-file-transfer%2F2%2FconsoleText=02%7C01%7Cv-alsoro%40microsoft.com%7C9ab9ec2d342a40ee3aee08d41d5e8c4d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636165739303098482=XQq%2F4FDHoCdK51iqBNoQPlgbB%2BFtLHA67yiKOtDS9ZU%3D=0
> [2] 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcordova-ci.cloudapp.net%3A8080%2Fview%2FPeriodic%2520builds%2Fjob%2Fcordova-periodic-build%2FPLATFORM%3Dandroid-4.4%2CPLUGIN%3Dcordova-plugin-device-motion%2F247%2Fconsole=02%7C01%7Cv-alsoro%40microsoft.com%7C9ab9ec2d342a40ee3aee08d41d5e8c4d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636165739303098482=lXshEVOrBmnM4TXvlZIuOke4OcgjKOjx8NAiw3ASZy4%3D=0
> [3] 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcordova-ci.cloudapp.net%3A8080%2Fcomputer%2Fmac-slave%2Fload-statistics%3Ftype%3D

An idea for manually testing plugins

[Filip Maj]

Hi, it's me again!

How I'd like to contribute to Cordova is to help automate the stuff
that saves committers having to take the manual time to do themselves.
I think a good first goal would be to help automate as much of
platform release testing as possible [1]. The autotests seem to be
handled relatively well by the CI system so far (if anyone feels this
is not true, please speak up! I want to hear about what works and what
does not). The other part of mobile-spec-based platform release
testing is to "run the manual tests". After reading the
cordova-plugin-test-framework README [2], I thought this would be a
good place to give plugin developers some better tools to deal with
testing complex UI interactions that the autotests can't handle on
their own. I was thinking appium [3] would be a good tool to
complement that in this case. It gives us UI hooks into both web and
natives contexts within hybrid applications, plus it also allows us to
inject JavaScript into the web context. Wondering what others think?

I could then foresee, with a little bit of scaffolding, a way to
string plugins' appium tests together to fully automate the 'manual'
testing of plugin tests during platform release testing.

Let me know what y'all think!

[1] 
https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#what-to-test
[2] 
https://github.com/apache/cordova-plugin-test-framework#defining-manual-tests
[3] appium.io

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Access to Jenkins instance, questions about CI

[Filip Maj]

Dearest Cordova devs,

I would like to get admin-level access to the cloudapp jenkins
instance: http://cordova-ci.cloudapp.net:8080/

Who can grant me this karma?

I wanted to check out how the various jobs are configured, what
triggers them and what the triggered code looks like.

I also wanted to fix some things I've noticed:
 - File Transfer tests relying on Alex Sorokin's fork of paramedic,
which now seems to be gone, and thus fails the job [1]
 - I noticed some popd/pushd errors in the periodic builds for
specific plugins, as well as npm error output [2]. Seems to be related
to a missing cordova-create directory or something.

Had some followup questions too!
 - When a worker node goes down or becomes inaccessible, that may fail
a build. (see e.g. the Mac node graphs [3]). When this happens, do we
get alerted? And how would do we fix it?
 - In the Periodic Builds section [4], what is the difference between
the "build" [5] and the "test" [6] jobs? The test jobs seem to only
care about network information and file transfer plugins, but other
than that, I'm wondering what the vision here is?

[1] 
http://cordova-ci.cloudapp.net:8080/view/Periodic%20builds/job/cordova-periodic-test/PLATFORM=android-4.4,PLUGIN=cordova-plugin-file-transfer/2/consoleText
[2] 
http://cordova-ci.cloudapp.net:8080/view/Periodic%20builds/job/cordova-periodic-build/PLATFORM=android-4.4,PLUGIN=cordova-plugin-device-motion/247/console
[3] 
http://cordova-ci.cloudapp.net:8080/computer/mac-slave/load-statistics?type=hour
[4] http://cordova-ci.cloudapp.net:8080/view/Periodic%20builds/
[5] 
http://cordova-ci.cloudapp.net:8080/view/Periodic%20builds/job/cordova-periodic-build/
[6] 
http://cordova-ci.cloudapp.net:8080/view/Periodic%20builds/job/cordova-periodic-test/

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Vote] 4.3.1 iOS Release

[Filip Maj]

I vote +1

I ran the following tests against an iOS 10.1 iPhone 7 plus simulator

1. mobilespec
autotests
- i get the two media failures that seem to be expected (at least per
Kerri’s vote)
- i get file.spec.147 failure every time w/ code:1 NOT_FOUND_ERR. manual
file tests all pass fine, though.
- i get two file transfer failures, either spec.42 or spec.44 (they seem to
alternate?), plus spec.45, when using evening-reaches-13417.herokuapp.com
as the remote FT server

manual tests - all worked (at least the ones that are simulator-compatible)
except:
- file-transfer: video download via cdvfile shows a broken play button and
unplayable video. via native works fine.
- media: on step 7 of the recommended test procedures (pressing play after
pressing release), track does not start playing and log shows an Audio
Error: 4. System Log does not glean anything more.

2. ./bin/create + ./cordova/build + ./cordova/run works fine

On Thu, Dec 1, 2016 at 10:32 AM, Kerri Shotts  wrote:
> I vote +1:
>
> Created mobilespec for ios
> Ran mobilespec auto tests on iOS emulator, some failures (all expected on
my end: file-transfer & 2 media tests)
> Ran npm test, no errors
> Created hello-world app via CLI, OK
> Ran on device OK
> Upgraded app via CLI, OK
> Ran cordova-lib tests, no errors
> Tested storyboard launch images, OK
> Ran on device, OK
>
> ~ Kerri
>
>> On Nov 30, 2016, at 19:28, Shazron  wrote:
>>
>> Please review and vote on this 4.3.1 iOS Release
>> by replying to this email (and keep discussion on the DISCUSS thread)
>>
>> Release issue: https://issues.apache.org/jira/browse/CB-12203
>>
>> The archive has been published to dist/dev:
>> https://dist.apache.org/repos/dist/dev/cordova/CB-12203
>>
>> The package was published from its corresponding git tag:
>> cordova-ios: 4.3.1 (8fe24d41b0)
>>
>> Note that you can test it out via:
>>
>> cordova platform add https://github.com/apache/cordova-ios#4.3.1
>>
>> Upon a successful vote I will upload the archive to dist/, publish it to
>> npm, and post the blog post.
>>
>> Voting guidelines:
>> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>>
>> Voting will go on for a minimum of 48 hours.
>>
>> I vote +1:
>> * Ran coho audit-license-headers over the relevant repos
>> * Ran coho check-license to ensure all dependencies and sub-dependencies
>> have Apache-compatible licenses
>> * Ensured continuous build was green when repo was tagged
>

Re: [Vote] 4.3.1 iOS Release

[Filip Maj]

The release notes in coho [1] note to check npm outdated dependencies.
When I run that against commit
0c201c42344f63c7590c4190ba2285fa199300bb, I get:

~/src/cordova-ios on master via ⬢ v6.9.1
➔ npm outdated --depth=0
Package   Current  Wanted  Latest  Location
nodeunit0.8.8   0.8.8  0.10.2  cordova-ios
plist   1.2.0   1.2.0   2.0.1  cordova-ios
shelljs 0.5.3   0.5.3   0.7.5  cordova-ios
tmp0.0.26  0.0.26  0.0.31  cordova-ios

I might be rusty, is this a showstopper? Or do we not care about this
and the release notes need updating?

[1] 
https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#update-and-pin-dependencies

On Wed, Nov 30, 2016 at 5:28 PM, Shazron  wrote:
> Please review and vote on this 4.3.1 iOS Release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12203
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-12203
>
> The package was published from its corresponding git tag:
> cordova-ios: 4.3.1 (8fe24d41b0)
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-ios#4.3.1
>
> Upon a successful vote I will upload the archive to dist/, publish it to
> npm, and post the blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and sub-dependencies
> have Apache-compatible licenses
> * Ensured continuous build was green when repo was tagged

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Hello again!

[Filip Maj]

Thanks for the clarification Alexander! I think I got confused between
the PR and periodic builds. I see in the periodic builds, indeed the
job is cloning down the relevant platform and using the latest HEAD
from master. In the PR builds, the logs are sparser and don't
explicitly log out versions of dependent libraries consumed, so I will
assume you are right!

I have one more question: how does everyone feel about cordova-qa's
GitHub comments with test results (passing example: [1], failing
example: [2])? What about integrating these kinds of checks into the
GitHub UI for per-commit checks (this is the green checkmark you'll
see in GH UI)? I'm probably missing a reason why it is integrated in
this way, so forgive me if it's a naive question :)

It looks like Travis test runs are integrated using the GitHub
pass/fail integrations / UI. I'm wondering why not the Jenkins tests?
I believe we can set up the integration such that each discrete check
(i.e. a specific plugin/platform combination) can set up as a separate
check, posting a separate result. Might be less confusing / less "made
in house" than a custom QA bot? Just a thought. Currently, the 'fail'
comment from cordova-qa requires contributors to click through all the
various links to figure out which particular platform errored out. By
splitting the checks out, it would make that more apparent more
immediately.

I think the UI as viewed from GitHub would be cleaner: from the pull
req list it would be instantly visible which PRs are passing and which
are failing, and the merge instructions could be simplified to "if the
green check mark shows up, merge away", instead of right now needing
to wait for both the green checkmark representing Travis + cordova-qa
bot comment.

It's a UI nitpick but I think it might improve the contribution
experience. Feel free to shoot me down or direct me to more pressing
issues :D

[1] 
https://github.com/apache/cordova-plugin-device/pull/58#issuecomment-263793786
[2] 
https://github.com/apache/cordova-plugin-camera/pull/131#issuecomment-263013516

On Tue, Nov 29, 2016 at 12:28 AM,  <alsoro...@apache.org> wrote:
> Hi again Filip, you are most welcome!
>
>>> - cordova-paramedic configs are pulled from cordova-medic repo.
>>> (?) requires an extra pull in CI.
> Yeah. This is kind of rudimentary thing, I think we can safely transfer them 
> to cordova-paramedic repo. This will require some Jenkins jobs changes, I can 
> assist with that.
>
>> >  - paramedic setup for individual plugins install latest HEAD of
>> > master of platform code (at least, cordova-android + device plugin)
> What makes you think so? I double-checked, our current CI setup for per-PR 
> jobs is using the released versions of all the platforms. Master versions are 
> used only for periodic build.
>
>> >  - there are plugins tests that run via a jenkins instance on
>> > cloudapp.net, and there are travis tests too. travis is pull-req
>> > triggered, cloud app runs nightly. why?
> Regarding cloudapp (Jenkins) builds:
> The goal of nightly tests is to verify the master versions of plugins against 
> the master versions of platforms and CLI. We also run per-PR jobs against the 
> released versions of platform and CLI, you can find them here:
> http://cordova-ci.cloudapp.net:8080/view/Pull%20requests/
>
> Feel free to contact me via email or Slack if you have any questions 
> regarding our current CI setup or need an assistance.
>
> Thanks,
> Alexander Sorokin
>
> -Original Message-
> From: Jesse [mailto:purplecabb...@gmail.com]
> Sent: Monday, November 28, 2016 11:00 PM
> To: dev@cordova.apache.org
> Subject: Re: Hello again!
>
> Welcome back!
>
>
> @purplecabbage
> risingj.com
>
> On Mon, Nov 28, 2016 at 11:50 AM, Simon MacDonald <simon.macdon...@gmail.com
>> wrote:
>
>> Never heard of this guy.
>> Simon Mac Donald
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsimonm
>> acdonald.com=02%7C01%7Cv-alsoro%40microsoft.com%7Cdcdee276682a4ff
>> 9353408d417c92e87%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6361596
>> 00215033744=zPpzT0F5p5rlW71wFWe0DtB2cG8rednMPQyiqtUw%2BZg%3D
>> erved=0
>>
>>
>> On Mon, Nov 28, 2016 at 2:48 PM, Filip Maj <maj@gmail.com> wrote:
>> > Hi everyone!
>> >
>> > Just wanted to (re)introduce myself after a 3 year or so hiatus :)
>> >
>> > I used to be an active member of the group between 2011 and 2013
>> > when I was on the Adobe PhoneGap team. I took a 3 year detour
>> > focusing on mobile testing infrastructure at Sauce Labs, but
>> > recently rejoined the Adobe PhoneGap team. I have been lurking more
>> > intently on this list for the past month o

Hello again!

[Filip Maj]

Hi everyone!

Just wanted to (re)introduce myself after a 3 year or so hiatus :)

I used to be an active member of the group between 2011 and 2013 when
I was on the Adobe PhoneGap team. I took a 3 year detour focusing on
mobile testing infrastructure at Sauce Labs, but recently rejoined the
Adobe PhoneGap team. I have been lurking more intently on this list
for the past month or so and aim to be more involved these days.

I've been poking around and getting my bearings around the testing
suites, infrastructure and CI in Cordova the past week or so. I think
I will try to contribute in that area initially. In particular, I am
interested in enabling functional end-to-end testing for all repos in
cordova that could benefit from that sort of testing, and seamlessly
integrating running the tests and reporting their results back into
the standard Cordova dev workflow (I assume that is focussed around
GitHub?). I see there are different kinds of test coverage and CI
systems at play (cloudapp, travis, appveyor, plus unit and functional
tests), so initially just wrapping my head around all that.

If anyone here has suggestions on areas that need work, have
grievances around how they are frustrated by manually needing to test
something, or having any other helpful tips on what needs work or what
could be improved, feel free to reply to this thread!

My generic notes on this topic so far, in case that is helpful:

cordova testing overview
———
notes / weird things:
 - cordova-paramedic configs are pulled from cordova-medic repo. (?)
requires an extra pull in CI.
 - paramedic setup for individual plugins install latest HEAD of
master of platform code (at least, cordova-android + device plugin)
 - there are plugins tests that run via a jenkins instance on
cloudapp.net, and there are travis tests too. travis is pull-req
triggered, cloud app runs nightly. why?

road to testing utopia:
 - how do platforms get tested? integration tests with what: tooling? plugins?
   - unit tests run on travis/appveyor?
   - understand what needs to be tested for a release. work backwards
to automate that from there. Steve sent some helpful links my way:
 - platform:
https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#testing
 - plugins:
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#test
 - tools: 
https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md#test
 - how do plugins get tested?
   - make sure dependencies / artifact versions are locked down.
   - what is the difference between "local" vs appium tests

Looking forward to collaborating with y'all in here once more :)

Cheers,
Fil

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Running file-transfer tests against local server

[Filip Maj]

Ideally we'd get Apache infra to fix up the VM, and we could build
some bandwidth caps into it and better monitoring into the instance to
get some more visibility into the situation should it go off the rails
again.

In the mean time, we should look at alternatives. I'll look into
hosting an alternative endpoint on some different hardware for now.
Maybe we can find a gracious corporate sponsor to host a modest
instance for us somewhere... :fingers_crossed:

On Wed, Oct 5, 2016 at 5:11 PM, Steven Gill  wrote:
> Thanks Alexander!
>
> On Wed, Oct 5, 2016 at 6:58 AM, Alexander Sorokin (Akvelon) <
> v-als...@microsoft.com> wrote:
>
>> Hi everyone,
>>
>>
>>
>> cordova-vm is still down and no one knows when it is going to be back up,
>> so I guess it's time to get things rollin' ourselves.
>>
>>
>>
>> You can now run file transfer plugin tests against locally deployed server
>> using Paramedic which will download and deploy file server automatically
>> every time you test a file transfer plugin.
>>
>> Please note though that right now only the master version of the plugin
>> knows how to work with local server.
>>
>>
>>
>> node cordova-paramedic/main.js --platform android --plugin
>> https://github.com/apache/cordova-plugin-file-transfer --cleanUpAfterRun
>>
>>
>>
>> If you don't want to use Paramedic, you can deploy file server locally and
>> then specify its address while installing cordova-plugin-file-transfer-
>> tests:
>>
>>
>>
>> cordova plugin add ../cordova-plugin-file-transfer/tests --variable
>> FILETRANSFER_SERVER_ADDRESS=http://10.0.0.2:5000
>>
>>
>>
>> Please note that the 'http://' bit is required.
>>
>>
>>
>> Thanks,
>>
>> Alexander Sorokin
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Split cordova-lib modules into their own repos

[Filip Maj]

+1

On Tue, Nov 22, 2016 at 9:33 PM, Darryl Pogue  wrote:
> On 22 November 2016 at 17:30, Steven Gill  wrote:
>> I propose to split these modules into their own git repos. Thoughts?
>
> A giant +1 from me!
>
> I routinely run into cases where cordova-common or cordova-lib
> problems have been fixed in master or I'm trying to test a branch, and
> I have no way of pointing a particular project on my CI system to use
> that branch without global npm link hackery (which doesn't even work
> properly with npm3). Definitely excited for this!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org