Re: Scoped package names for npm?

[Jesse]

re: the scoped package id, I like it, but not sure we want to change them
again ... and how much of our existing world will it break. Can we install
an '@' id currently on all platforms? It will result in a
www/plugins/@cordova/plugin-device/ folder right now, won't it?

re: other questions
Personally, I would rather see only committers able to publish to our scope
(assuming we go that way), just like we wanted to prevent non committers
from using org.apache.cordova namespace.

I considered 'cordova plugin add device' awhile back, I was going to do it
directly in plugman, but I decided against it. Currently it would mean a
3rd attempt to find the plugin over http; 1) cpr, 2) npm, 3)munge name and
go back to npm
By this time, I think I would just ask the user what they really want.
We could also do this via cordova-registry-mapper aliases.



@purplecabbage
risingj.com

On Mon, Apr 20, 2015 at 2:13 PM, Parashuram N (MS OPEN TECH) <
panar...@microsoft.com> wrote:

> Scopes are like namespaces. In the reverse domain name world,
> org.apache.cordova was considered a namespace, right ?
>
> We did not want non core packages to publish to that namespace, so does
> the same argument apply ?
>
> Alternatively, we can think of scope as packages that apply to a
> particular environment - for example, all cordova packages would be
> @cordova scope.
>
> -Original Message-
> From: Michal Mocny [mailto:mmo...@google.com]
> Sent: Monday, April 20, 2015 2:03 PM
> To: dev
> Subject: Re: Scoped package names for npm?
>
> Other questions to answer:
> - Can 3rd-parties publish to this scope?
>   - Do we want them to?
> - Do we want to default to @cordova scope if none is provided, such that
> you could do `cordova plugin add device`?
>
> -Michal
>
>
> On Mon, Apr 20, 2015 at 5:00 PM, Michal Mocny  wrote:
>
> > https://docs.npmjs.com/getting-started/scoped-packages
> >
> > Should we be @cordova/plugin-device instead of cordova-plugin-device?
> >
> > -Michal
> >
>

Re: Question about bypassing the run-loop wait/entire bridge for plugins on iOS

[Jesse]

I think you are best off to experiment and see what you can get working
consistently.  The focus lately has been on the wkwebview bridge, which is
entirely new, while the current webview implementation is a collection of
workarounds for various issues.

If you can distill this down to a simple project that demonstrates the
issue, I would be happy to have a look.




@purplecabbage
risingj.com

On Mon, Apr 20, 2015 at 3:25 PM, Tim Lancina  wrote:

> Whoops should probably have subscribed to the mailing list! Apologies if
> this screws up the thread.
>
> Thanks for your response Jesse. The problem is knowing when to start the
> css animation, hence why it would be best to be able to fire an event
> indicating the keyboard is about to show as quickly as possible.  If you
> wait for the run-loop, the animation will be behind by an arbitrary amount
> by the time it receives the event.  This isn't the end of the world, it
> just isn't as smooth and simultaneous as native.
>
> In the case of the keyboard plugin, all it does is trigger an event on the
> document indicating the keyboard will show/hide.  So if I'm understanding
> correctly, it would be better to leave the default evalJS
> scheduledOnRunLoop:YES call because the handlers for those events fired by
> the plugin could in theory result in more calls to native, correct?
>
> I suppose we could fire one event immediately, with the stipulation that
> handlers for the event shouldn't trigger any native calls, and another
> marginally slower, 'safe' event that could be used in most circumstances.
>
> If I'm making any false assumptions or overlooking something, please let me
> know!
>
> Best,
> Tim
>
> On Mon, Apr 20, 2015 at 4:45 PM, Josh Bavari  wrote:
>
> >
> > -- Forwarded message --
> > From: Jesse 
> > Date: Mon, Apr 20, 2015 at 1:39 PM
> > Subject: Re: Question about bypassing the run-loop wait/entire bridge for
> > plugins on iOS
> > To: "dev@cordova.apache.org" 
> >
> >
> > If you can be sure that your calls into js will not result in more calls
> > back to native, then it is probably fine. Delegating back to the main
> > thread may have similar performance trouble though ...
> >
> > For this specific case, can't you use a timed css animation that matches
> > the keyboard animation?
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Mon, Apr 20, 2015 at 12:18 PM, Tim Lancina  wrote:
> >
> > > Hey Andrew,
> > >
> > > Just had a quick question about plugins on iOS.  For the keyboard
> plugin
> > > we're using evalJS to fire an event when the keyboard shows, which by
> > > default waits for the run loop to cycle before executing any JS.  My
> > > question is, would terrible things happen if we didn't wait, or even
> just
> > > went straight stringByEvaluatingJavaScriptFromString?  I can see from
> the
> > > commented code (
> > >
> > >
> >
> https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVCommandDelegateImpl.m#L83
> > > )
> > > that there are certain scenarios where it looks like you need to wait,
> > but
> > > was wondering if those are extreme edge cases or regular occurrences.
> > >
> > > The reason I'm asking is that we had someone bring up an issue on the
> > Ionic
> > > issue tracker about getting the keyboard plugin to fire quickly enough
> so
> > > they could animate an element along with the keyboard animation like on
> > > native.  The issue is here:
> > https://github.com/driftyco/ionic/issues/3537,
> > > but I was hesitant to give them a definitive answer on either bypassing
> > the
> > > wait or not.  It would also be nice to update the plugin if bypassing
> the
> > > wait isn't an issue in most cases.
> > >
> > > Cheers,
> > > Tim
> > >
> >
> >
> >
> > --
> > "Clear thoughts produce clear results."
> > Josh Bavari
> > Application Developer
> > Phone: 405-509-9448
> > Cell: 405-812-0496
> > Email: jbav...@gmail.com
> >
>

Re: [PROPOSAL] Update Cordova iOS Platform Xcode Compatibility

[Jesse]

+1

> On Feb 10, 2020, at 6:02 AM, julio cesar sanchez  
> wrote:
> 
> +1
> 
> note that maybe it's not clear, but we would remove Xcode 10 support as
> using the Xcode 11 structure will make apps incompatible with previous
> Xcode versions.
> 
> Dropping Xcode 10 support can also simplify some plugins code that have
> additional code macros to work on Xcode 10 at the moment.
> 
> 
>> El lun., 10 feb. 2020 a las 14:54, Bryan Ellis ()
>> escribió:
>> 
>> I accidentally clicked on the send button before adding the PR link that I
>> already submitted.
>> 
>> https://github.com/apache/cordova-ios/pull/780
>> 
>> I also *+1* for setting the "*Project Format*" to "*Xcode 11-compatible*"
>> 
>> 
>>> On Mon, Feb 10, 2020 at 10:51 PM Bryan Ellis  wrote:
>>> 
>>> I would like to open the discussion and vote to *update the Cordova iOS
>>> Xcode "Project Format" setting to Xcode 11-compatible* for the upcoming
>>> next major release.
>>> 
>>> I have already created a PR that performs the changes but would like to
>>> get feedback from others regarding this change in general and maybe a
>>> review.
>>> 
>>> One of the major reasons for this change is to conform with the *App
>>> Store Submission[1]* guidelines:
>>> 
>>> Starting April, 2020, all apps submitted to the App Store will need to be
>>> built with Xcode 11. Xcode 11 requires macOS Mojave 10.14.3 or later.
>>> 
>>> 
>>> Additionally,
>>> 
>>> This change would modernize our default project template, CordovaLib, and
>>> as well as the testing fixtures.
>>> 
>>> And also, quoted from Apple's *WWDC 2019 Video[2]*
>>> 
>>> Keeping your project file modern is a critical way to make sure that
>> Xcode
>>> can help you out and avoids the accumulation of issues.
>>> First, when you're updating to a new version of Xcode, you'll be offered
>>> the opportunity sometimes to have Xcode update the project settings and
>>> update your project file to the latest format.
>>> 
>>> 
>>> *Reference Links*
>>> *App Store Submission*
>>> [1] https://developer.apple.com/app-store/submissions/
>>> 
>>> *WWDC 2019 Video*
>>> [2] https://developer.apple.com/videos/play/wwdc2019/239/
>>> 
>> 

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

Draft March 2020 Board Report

[Jesse]

Draft is committed here:
https://github.com/apache/cordova-apache-board-reports/blob/master/2020/2020-03.md

Sorry for the short turn around, this needs to be submitted today.
Please let me know if there is anything you want added/changed.

Cheers,
  Jesse

Re: UiwebView deprecated issue for my App

[Jesse]

Hi Binay,

This list is for development of Apache Cordova itself.  For issues using
Apache Cordova in your app, your best bet is either via our slack channel
[1]
or stack overflow [2]
That said, it sounds like Ionic support might be a better option for your
issue.

Cheers,
  Jesse


[1] https://slack-cordova-io.herokuapp.com/
[2] https://stackoverflow.com/questions/tagged/cordova

On Tue, Mar 31, 2020 at 5:40 PM Binay Prabhakar  wrote:

> Hi Corodova Team,
> Six month back when I started working on Ionic App I was Very excited
> about it.
> But things are not smooth since few weeks.
> When I uploaded my app to test flight there were UI Web View depreciated
> warning came to me.
> To solve it i have migrated the app to Ionic 5 with a hope that this issue
> will be solved.
> But sad part is that still Apple gave the same warning of Ui depreciation.
> Can you please help me on this!
> Tried everything..Even created sample ionic project in ionic 5 and tried
> to build it but in ios code what I can see is there are references of
> UiwebView.
> Any proper blog will be helpful if you can suggest.
>
>
> Get Outlook for Android<https://aka.ms/ghei36>
>

Re: UiwebView deprecated issue for my App

[Jesse]

 minus Binay

This is the developer cordova list, we don't need to continue to pile on
this thread.
The question has been answered.

On Wed, Apr 1, 2020 at 12:39 AM julio cesar sanchez 
wrote:

> There is also an entry about it on the Apache cordova blog
>
> https://cordova.apache.org/howto/2020/03/18/wkwebviewonly.html
>
> But as Chris said, doesn’t look like you did any research, if you google “
> *ITMS-90809”* (the error you get when you submit the app),  the first
> result is the ionic blog post he linked.
>
>
> El miércoles, 1 de abril de 2020, Chris Brody 
> escribió:
>
> > The answer is already documented. We would really appreciate it if users
> > could a little more research since maintainers are generally overloaded,
> > especially while they are busy with a new major release.
> >
> > That said, here is a recommended link that I found from a quick search:
> > https://ionicframework.com/blog/understanding-itms-90809-
> > uiwebview-api-deprecation/
> >
> > I do think our documentation could use some improvement, and it has
> already
> > been sponsored by an anonymous donor:
> > https://github.com/apache/cordova-docs/issues/1057
> >
> >
> > On Tue, Mar 31, 2020 at 8:48 PM Jesse  wrote:
> >
> > > Hi Binay,
> > >
> > > This list is for development of Apache Cordova itself.  For issues
> using
> > > Apache Cordova in your app, your best bet is either via our slack
> channel
> > > [1]
> > > or stack overflow [2]
> > > That said, it sounds like Ionic support might be a better option for
> your
> > > issue.
> > >
> > > Cheers,
> > >   Jesse
> > >
> > >
> > > [1] https://slack-cordova-io.herokuapp.com/
> > > [2] https://stackoverflow.com/questions/tagged/cordova
> > >
> > > On Tue, Mar 31, 2020 at 5:40 PM Binay Prabhakar 
> > > wrote:
> > >
> > > > Hi Corodova Team,
> > > > Six month back when I started working on Ionic App I was Very excited
> > > > about it.
> > > > But things are not smooth since few weeks.
> > > > When I uploaded my app to test flight there were UI Web View
> > depreciated
> > > > warning came to me.
> > > > To solve it i have migrated the app to Ionic 5 with a hope that this
> > > issue
> > > > will be solved.
> > > > But sad part is that still Apple gave the same warning of Ui
> > > depreciation.
> > > > Can you please help me on this!
> > > > Tried everything..Even created sample ionic project in ionic 5 and
> > tried
> > > > to build it but in ios code what I can see is there are references of
> > > > UiwebView.
> > > > Any proper blog will be helpful if you can suggest.
> > > >
> > > >
> > > > Get Outlook for Android<https://aka.ms/ghei36>
> > > >
> > >
> >
>

Re: Frustration with Cordova documentation

[Jesse]

Sounds good.
I will tweet the blog post as well so we can try to stay ahead of the
questions.

On Wed, Apr 1, 2020 at 12:44 AM julio cesar sanchez 
wrote:

> Maybe we should add the error code on the blog entry (*ITMS-90809*), that
> way people can end up on the blog when searching about. Right now first
> entry is the ionic blog, I checked 5 pages and didn’t find anything cordova
> specific.
>
> El miércoles, 1 de abril de 2020, Niklas Merz 
> escribió:
>
> > I think there is good documentation for this particular problem. I wrote
> a
> > blog post {1} just two weeks ago to summarize it now that Apple is
> > enforcing it. Most people just don't research properly and just ask and
> we
> > can't do anything about it.
> >
> > But yes we really should get this money for better docs used now. I just
> > don't know how to get this going. I guess we need to find a technical
> > writer/developer capable of doing it.
> >
> > {1} https://cordova.apache.org/howto/2020/03/18/wkwebviewonly.html
> >
> > April 1, 2020 2:58 AM, "Chris Brody"  wrote:
> >
> > > Improvement has already been sponsored by an anonymous donor. Repeated
> > > requests for help with getting it started have been met with no
> response
> > so
> > > far. I think this recent thread is an example of how our documentation
> > > could use some improvement:
> > >
> > > https://lists.apache.org/thread.html/r261aa09ef8e4b0d47ceda731d38a5
> > 8204186d544528b07c27898c000@ > > ordova.apache.org>
> > >
> > > I sincerely hope I am just missing something here, would love to get
> the
> > > ball rolling in the near future.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: [VOTE] Cordova-Fetch 3.0.0 Release (April 9 - Second Vote)

[Jesse]

+1

- coho verify-archive
- CI is green
- checked out tag and ran tests


On Wed, Apr 8, 2020 at 11:38 PM Niklas Merz  wrote:

> I vote +1
>
> Successfully checked
> * Confirmed sigs & hashes with `coho verify-archive`
> * Verified sha521s match tags manually
> * CI is green
> * run 'npm install' in package
> * tests success on local
> * LICENSE and NOTICE exist
>
> April 9, 2020 4:04 AM, "Bryan Ellis"  wrote:
>
> > Please review and vote on this Cordova Fetch Major Release v3.0.0
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The archive has been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/fetch-3.0.0
> >
> > The package was published from its corresponding git tag:
> > cordova-fetch: 3.0.0 (25e89034df)
> >
> > 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
> > * Ensured continuous build was green when repo was tagged
> > * NPM Audit
> > * NPM Test
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [VOTE] cordova-app-hello-world 5.0.0 Release

[Jesse]

+1

- coho verify-archive
- reviewed code

On Tue, Apr 7, 2020 at 7:28 PM Bryan Ellis  wrote:

> Please review and vote on this cordova-app-hello-world Major Release v5.0.0
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/app-hello-world-5.0.0
>
> The package was published from its corresponding git tag:
> cordova-app-hello-world: 5.0.0 (70084d1bab)
>
> 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 (gitignore is
> excluded)
> * Ran coho check-license to ensure all dependencies and subdependencies
> have Apache-compatible licenses (No Dependencies)
> * NPM Audit (No Package)
> * NPM Test (No Tests)
> * Built locally a CLI which has cordova-create tied with
> cordova-app-hello-world@5.0.0.
> * Created a new cordova project
> * Tested a platform add, build, and run with Android
>

Re: [VOTE] cordova-serve 4.0.0 Release

[Jesse]

+1

- ran coho verify-archive
- CI green
- checked out tag, ran tests


On Wed, Apr 8, 2020 at 12:02 AM Bryan Ellis  wrote:

> Please review and vote on this cordova-serve Major Release v4.0.0
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/serve-4.0.0
>
> The package was published from its corresponding git tag:
> cordova-serve: 4.0.0 (e2b078ff5b)
>
> 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
> * Ensured continuous build was green when repo was tagged
> * NPM Audit
> * NPM Test
>

Re: [VOTE] cordova-node-xcode 3.0.0 Release

[Jesse]

+1

- ran coho verify-archive
- code review
- CI green
- ran tests


On Thu, Apr 9, 2020 at 1:28 AM Bryan Ellis  wrote:

> Please review and vote on this cordova-node-xcode Major Release v3.0.0
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/node-xcode-3.0.0
>
> The package was published from its corresponding git tag:
> cordova-node-xcode: 3.0.0 (7b8d8439df)
>
> 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
> * Ensured continuous build was green when repo was tagged
> * NPM Audit
> * NPM Test
>

Re: [VOTE] cordova-js 6.0.0 Release

[Jesse]

+1

- coho verify-archive
- CI is green
- checkout tag, ran tests


On Wed, Apr 8, 2020 at 7:43 AM Niklas Merz  wrote:

> I vote +1
>
> * Confirmed sigs & hashes with `coho verify-archive`
> * Verified sha1s match tags with `coho verify-tags`
> * CI is green
> * run 'npm install' in package
> * tests success on local
> * checked licenses with coho and manually
>
> One minor issue:
>
> "npm audit" finds one low vulnerability for minimist
>
>
> April 8, 2020 6:22 AM, "Bryan Ellis"  wrote:
>
> > Please review and vote on this cordova-js Major Release v6.0.0
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The archive has been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/js-6.0.0
> >
> > The package was published from its corresponding git tag:
> > cordova-js: 6.0.0 (58c14e62c3)
> >
> > 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
> > * Ensured continuous build was green when repo was tagged
> > * NPM Audit
> > * NPM Test
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: vote: PR merge convention

[Jesse]

I made a mistake, no need to create laws or rules. 

> On May 2, 2020, at 11:21 AM, Tim Brust  wrote:
> 
> +1 to Niklas suggestion :)
> 
> Sent from my iPhone
> 
>>> On 2. May 2020, at 6:54 PM, Niklas Merz  wrote:
>>> 
>>> We could try to enforce this setting with .asf.yml. I saw this posted on 
>>> another list.
>>> 
>>> See: 
>>> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Mergebuttons
>>> 
>>> Should we roll this out to all repos?
>>> 
>>> May 2, 2020 1:38 PM, "julio cesar sanchez"  wrote:
>>> 
>>> Just a reminder that we agreed on using the squash and merge, but I still
>>> see regular merge commits in a few repos from time to time.
>>> 
>>>> El El sáb, 5 oct 2019 a las 19:32, gandhi rajan 
>>>> escribió:
>>>> 
>>>> + 1 for squash and merge as it makes the repo history cleaner.
>>>> 
>>>>> On Sat, Oct 5, 2019 at 8:34 PM  wrote:
>>>> 
>>>> +1 for "Squash and merge" as the default strategy
>>>> 
>>>> Regarding "Create a merge commit":
>>>> At times, I find this option valuable too. Consider a PR that cleans up a
>>>> test suite. As part of that cleanup I might re-order the test cases. As
>>>> re-ordering produces a noisy diff, I usually isolate it in its own
>>>> commit.
>>>> I would not want to merge this commit with the others as that would lead
>>>> to
>>>> a commit with a very incomprehensible diff. So in this case I would favor
>>>> leaving the commits separate and doing an actual merge to group them
>>>> together in the global history.
>>>> 
>>>> Am Fr., 4. Okt. 2019 um 17:03 Uhr schrieb julio cesar sanchez <
>>>> jcesarmob...@gmail.com>:
>>>> 
>>>>> Sorry if it wasn't clear, I said I was leaving the protecting master
>>>> branch
>>>>> out of the vote.
>>>>> 
>>>>> Looks like we all agree on using "Squash and merge" as default, unless
>>>> it
>>>>> makes more sense to use one of the other options.
>>>>> 
>>>>> El jue., 3 oct. 2019 a las 3:43, Bryan Ellis ()
>>>>> escribió:
>>>>> 
>>>>>> -1 for protected master branches.
>>>>>> Protecting a branch is a great idea except it does not work with our
>>>>>> current workflow process. COHO commits directly onto the master
>>>> branch
>>>>> for
>>>>>> releases. We would have to spend more time planning and changing our
>>>>> entire
>>>>>> current workflow process to eliminate direct commits if we wanted to
>>>>>> protect branches. There is alternative such keeping master open for
>>>>> direct
>>>>>> commits and development while creating a protected "production"
>>>> branch.
>>>>>> Anyways this part of the discussion is off-topic and could be another
>>>>>> discussion... Anyways, stated above I am downvoting protected
>>>> branches
>>>>> for
>>>>>> now.
>>>>>> 
>>>>>> +1 for "Squash and merge"
>>>>>> Makes a nice single commit with the PR number and without the extra
>>>> merge
>>>>>> commit.
>>>>>> 
>>>>>> +1 for "Rebase and merge"
>>>>>> There are use cases where this can work perfectly.
>>>>>> For example, Cordova-Electron has a `draft-2.0.0` branch which is
>>>>> targeting
>>>>>> the next major release. Major PRs were merged into that branch with
>>>>> "Squash
>>>>>> and merge". This means all PRs have nice PR# information in the
>>>> title.
>>>>>> A PR will later be created to merge this branch onto master. "Rebase
>>>> and
>>>>>> merge" will be used and will not create the merge commit message and
>>>> will
>>>>>> not squash.
>>>>>> 
>>>>>> -1 for "Create a merge commit"
>>>>>> Not in favor of the extra merge commit. I think in most cases one PR
>>>>> should
>>>>>> focus on one task so that means it could be squas

[Discuss] Cordova plugin camera release 4.2.0

[Jesse]

Does anyone have any reason to delay a cordova-plugin-camera release?
Any outstanding patches to land?

If not, I will start the release soon.

(CI is currently green)

[VOTE] Cordova plugin camera release 4.2.0

[Jesse]

Please review and vote on the release of corodova-plugin-camera
by replying to this email (and keep discussion on the DISCUSS thread)

The plugin has been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/Camera-4.2.0/

The packages were published from their corresponding git
tags:cordova-plugin-camera: 4.2.0 (adf15799d9)

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 sub-dependencies
have Apache-compatible licenses
* Ensured continuous build was green when repos were tagged

Re: [VOTE] Cordova plugin camera release 4.2.0

[Jesse]

The vote has failed, I am closing this.

On Thu, May 7, 2020 at 10:53 AM Niklas Merz  wrote:

> I vote -1
>
> I could not verify the packages signature. Importing the public keys
> from [1] did not give me a matching key.
>
> It looks strange and not like the GPG output I am used to.
>
> (sorry my machine is German)
> gpg: die unterzeichneten Daten sind wohl in
> 'cordova-plugin-camera-4.2.0.tgz'
> gpg: Signatur vom Do 07 Mai 2020 10:41:00 CEST
> gpg:mittels RSA-Schlüssel
> E6BDB1EAE1F49643A1A29ED213148950F12F403C
> gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel
>
>
> [1]
>
> https://github.com/apache/cordova-coho/blob/master/docs/setting-up-gpg.md#importing-pmc-members-pgp-keys
>
> Am 07.05.20 um 11:07 schrieb Jesse:
> > Please review and vote on the release of corodova-plugin-camera
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The plugin has been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/Camera-4.2.0/
> >
> > The packages were published from their corresponding git
> > tags:cordova-plugin-camera: 4.2.0 (adf15799d9)
> >
> > 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 sub-dependencies
> > 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: [Discuss] Cordova plugin camera release 4.2.0

[Jesse]

I have closed the vote for Camera-4.2.0
I will sort out my signing keys and restart tonight.

On Sun, May 3, 2020 at 11:08 PM Jesse  wrote:

> Does anyone have any reason to delay a cordova-plugin-camera release?
> Any outstanding patches to land?
>
> If not, I will start the release soon.
>
> (CI is currently green)
>

Re: Request to add to dev mailing list

[Jesse]

Welcome Devendra,

If you would like more info on contributing, there is a ton of info here:
https://cordova.apache.org/contribute/contribute_guidelines.html
As well, I believe those on this list would be supportive if you have
questions, or need help contributing.

That said, please remember that this list is specifically for developing
Apache Cordova, and is not a community support forum for apps built with
Cordova.
The  #slack community is a great place to ask and answer questions as well.
http://slack.cordova.io/

Cheers,
  Jesse

On Wed, May 13, 2020 at 12:01 PM Devendra Khatri 
wrote:

> Hello,
>
> I have been working on cordova platform for past 3-4 years, I Keep reading
> blogs about the platform to keep our product stable. I came across this
> listing recently, If you can add me in the listing !
>
> Also, let me know If I need to know any thing else here !!
>
> Thanks
> Devendra
>

Re: Strongly deprecating the FileTransfer plugin

[Jesse]

+1 The deprecation notice needs to be prominent, I missed it myself on a
quick scroll.
Some of that readme is in a specific format to support appearance in
docs.cordova.io ( similar to
https://cordova.apache.org/docs/en/latest/reference/cordova-plugin-file/index.html
 )
This is no longer a requirement, so we can go prominent.
We should also ask INFRA to put the text [DEPRECATED] in the description,
and possibly even archive the repo.


On Wed, Jun 3, 2020 at 12:02 PM Norman Breau  wrote:

> I'm sure you're not the only one who misses it, considering the repo is
> still pretty active in terms of new issues being reported.
>
> On 2020-06-03 3:59 p.m., Darryl Pogue wrote:
> > Correction: There is in fact a deprecation notice, part-way down the
> > README, but it's not especially attention grabbing and I missed it the
> > first 2 times I skimmed the file.
> >
> > On Wed, Jun 3, 2020 at 11:55 AM Darryl Pogue  wrote:
> >
> >> Hey folks,
> >>
> >> The File Transfer plugin has been officially deprecated since 2017:
> >>
> https://cordova.apache.org/blog/2017/10/18/from-filetransfer-to-xhr2.html
> >>
> >> However, the repo and npm have no link to that page or any sort of
> >> indication that it is not maintained.
> >>
> >> With the release of cordova-ios 6, the FileTransfer plugin no longer
> >> compiles on iOS:
> >> https://github.com/apache/cordova-plugin-file-transfer/issues/258
> >>
> >> I want to reply to that issue saying that it's deprecated and not
> >> maintained, but I feel like we haven't made that very clear.
> >>
> >> I would like to propose that we update the README for File Transfer
> with a
> >> clear deprecation notice which links to the blog post from 2017, and
> that
> >> we ask ASF Infra to mark the repo as archived.
> >>
> >> Any objections?
> >>
> >> ~Darryl
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

June board report

[Jesse]

Sorry for the short notice, the June Board Report is due today.

Please review and reply if you have any additions, revisions, or questions.
https://github.com/apache/cordova-apache-board-reports/blob/master/2020/2020-06.md

If it's all good, I'll be submitting it later this evening.

Cheers,
  Jesse

Re: June board report

[Jesse]

good catch ... it wasn't calculated!

On Wed, Jun 10, 2020 at 3:54 PM julio cesar sanchez 
wrote:

> How is this calculated?
>
> Issue close rate of 57%:
>
>- 300 issues opened on GitHub, past quarter
>- 311 issues closed on GitHub, past quarter
>
> 311 closed for 300 opened is more than 100%
>
> El El jue, 11 jun 2020 a las 0:29, Jesse 
> escribió:
>
> > Sorry for the short notice, the June Board Report is due today.
> >
> > Please review and reply if you have any additions, revisions, or
> questions.
> >
> >
> https://github.com/apache/cordova-apache-board-reports/blob/master/2020/2020-06.md
> >
> > If it's all good, I'll be submitting it later this evening.
> >
> > Cheers,
> >   Jesse
> >
>

ApacheCon 2020 CFP

[Jesse]

ApacheCon has an open call for presentations.  If anyone is interested in
presenting something related to Apache Cordova, I will help however I can.
I gave 2 presentations (to help fill a Cordova/mobile track) last year at
Apache Con in Vega$, and while the attendance was disappointing, it was a
great experience.  This year is all online, so no need to travel (or wear
pants), and you will probably reach a larger audience than I did.

https://www.apachecon.com/acna2020/cfp.html

PS You do NOT need to be a Cordova pmc, committer, Apache member, ... or
anything else to present.

Re: Keystore password prompt

[Jesse]

My suggestion would be to remove the prompt, and insist that the value
either come from build.json
and/or if we are willing to do a little more work, it could come from an
env variable
SIGNING_PASSKEY=123123kasdj cordova build android --release

On Wed, Jul 15, 2020 at 7:08 PM Norman Breau  wrote:

> If we deprecate the password prompt feature and remove in the next
> major, this leaves the user with the following options:
>
> - Use build.json to have cordova sign apps for the user automatically.
> - Not use build.json, which gives the user the unsigned apk, which
> they'll have to sign themselves using the appropriate tools.
>
> Using the jarsigner I know has similar features where if you don't pass
> in the password fields, then they'll prompt the user. So if we really
> wanted to keep the feature... I could perhaps look at removing the
> signing out of gradle, then make the cordova tooling use the jarsigner
> tool... which is a tool that is included with java. It may be more
> reliable than gradle.
>
> But personally I'm in favour of removing the feature altogether in the
> next major.
>
> On 2020-07-15 10:39 p.m., Chris Brody wrote:
> > I think we should not be making our own password-based or other secure
> > build tools within the Cordova project unless it is absolutely necessary.
> >
> > This looks like a problem that is not unique to Cordova app development.
> >
> > I think this is something that should be done by other tools such as
> > Gradle, Android Studio, Android command-line tool, etc.
> >
> > I think it would be much safer to leave this kind of thing to underlying
> > tools, which have both a wider audience and are more likely to have the
> > right kind of expertise, than our own tooling.
> >
> > In case any of us are able to make a password-based build tool that could
> > help others, and it could benefit our users, that would be awesome.
> >
> > I would compare this to the way that Capacitor expects users to use
> > platform-specific IDEs to build and run on the mobile platforms.
> >
> >
> > On Wed, Jul 15, 2020 at 9:24 PM Norman Breau 
> wrote:
> >
> >> Hi Team,
> >>
> >> Looking for some opinions on the keystore password prompt, when building
> >> for android.
> >>
> >> TL;DR; is this feature worth keeping?
> >>
> >> If you're not aware, if you leave either the store password or the key
> >> password blank/empty string inside
> >> the build.json file, then we have a gradle implementation to prompt the
> >> user for a password.
> >>
> >> It was recently been discovered that it was broken.I went back several
> >> versions of both gradle and cordova-android, but I was unable to find
> >> when it was not broken. Some research suggest that the prompt would have
> >> been broken since gradle 3.x.
> >>
> >> There is two problems with the prompt. The first issue is that when
> >> using a gradle daemon, or if you change any of the default java settings
> >> (which we do, cause we need to set -Xmx to at least 2gb to handle
> >> android builds with dex), then gradle will spawn a subprocess to do a
> >> gradle build. This means gradle does not have a console attached and
> >> cannot receive user input.
> >>
> >> cordova-android currently will fail with "Failed to create component for
> >> 'dialog' reason: java.awt.HeadlessException"
> >>
> >> I've created a PR that addresses this issue by making the password
> >> prompt use a GUI, if the console is not available, which works, but
> >> exposes the second issue. I've spent a considerable amount of time
> >> trying to fix but I haven't been able to find a solution.
> >>
> >> The issue is that gradle password prompts doesn't appear to work at all,
> >> regardless if you use the GUI method, or the console input method. It
> >> always results in a "Keystore was tampered with, or password was
> >> incorrect".
> >>
> >> I've observed this using my own keystore I use for apps. If I put the
> >> password in the build.json file, it works. If I use the password prompt,
> >> it doesn't work. I've produced logging to determine that the password
> >> prompt is receiving the correct text as expected, and I've confirmed
> >> that the android signingConfigs has the correct information. It's a
> >> rather weird problem, and you can try this yourself by applying the
> >> prompt fix PR.
> >>
> >> I've already talked to Erisu about possible workarounds, but we
> >> determined if we need this feature, the implementation must be kept at
> >> the gradle level. Otherwise, you'll be introducing security
> >> vulnerabilities.
> >>
> >> So before I spend anymore time on this, I want to gather thoughts,
> >> particularly if this feature is even worth keeping. It's only use case
> >> would be for end users who prefer not to store their password on the
> >> filesystem. Obviously it can't be use for CI or much other purposes.
> >> Given that it's been broken for so long without complaints, I don't
> >> think the feature is commonly used. The individual who recently brought
> >> at

Twitter Together is setup

[Jesse]

Hello all,

I finally got to adding twitter together to the apache/cordova repo.
If you want to tweet via the @apachecordova twitter account, you just need
to open a pull-request in the tweets/ directory.

More instructions here: https://github.com/apache/cordova/tree/master/tweets

There are currently no rules, if you have commit access, you can tweet ...
so please do not abuse this.  Run your pr past some other committers, get
input, ... request a review ... be nice!!!

Cheers,
  Jesse

Cordova Committer Video Chat

[Jesse]

Hey all,

I started a doodle to find the best time for us to meet.  Please enter your
preferences, you should be able to see all choices in your timezone.

https://doodle.com/poll/huw5d8eemh83gim5

Cheers,
  Jesse

Re: Cordova Committer Video Chat

[Jesse]

Thanks Chris,
Yes, that is the intent. All are welcome, but the agenda will be defined by
pmc.
I would like us to evolve this into a regular occurrence so we can show our
work a little more widely.

Cheers,
  Jesse


On Mon, Aug 17, 2020 at 10:37 AM Chris Brody  wrote:

> My understanding from private correspondence is that this is open for
> anyone to join or listen into (Jesse can you clarify?) and join the poll on
> Doodle, priority is of course a little higher for committers & PMC members.
>
> Thanks Jesse for organizing this, much needed!
>
> On Mon, Aug 17, 2020 at 1:15 PM Jesse  wrote:
>
> > Hey all,
> >
> > I started a doodle to find the best time for us to meet.  Please enter
> your
> > preferences, you should be able to see all choices in your timezone.
> >
> > https://doodle.com/poll/huw5d8eemh83gim5
> >
> > Cheers,
> >   Jesse
> >
>

Re: [DISCUSS] NPM Package Deprecation

[Jesse]

I think this stance is too aggressive. 

For minor version bumps there is no need to deprecate the previous minor as any 
support request should be met with ‘update’

For major versions, the fact that a new major is released should not be the 
defining factor, we cannot expect everyone to be able to immediately jump on a 
new version. In a dependency ridden world there is never a guarantee developers 
can even update. 

I think we should look at other major projects ( node itself even ) for 
inspiration. 
Ignore odd/even majors, I suggest reading thru 
https://nodejs.org/en/about/releases/



> On Aug 18, 2020, at 6:31 AM, Chris Brody  wrote:
> 
> 
>> 
>> * When releasing a patch, deprecate the last patch release within the same 
>> subset.
> 
> +1
> 
>> * When releasing a minor, nothing happens.
> 
> I would favor a slightly more flexible approach on this:
> 
> - only support 1-2 minor versions back
> - It goes without saying that if a security release needs a minor
> release, which seems to have happened on Node.js, then previous
> minor(s) should be deprecated.
> - If a critical update needs a minor release, consider deprecating
> previous minor(s).
> 
> Though we did not seem to have very many minor releases between the
> recent major releases.
> 
>> * When releasing a major, deprecate the entire previous major (including 
>> patches and minors).
> 
> +1
> 
>> I will start a vote within 12-24 hours after keeping this discussion thread 
>> open for any feedback, modifications, or additions.
> 
> +1
> 
> I wonder if there should be a draft PR on cordova-coho before stariing the 
> vote?
> 
>> I will be creating a separate discussion thread & vote for actually 
>> deprecating the existing out-dated npm package.
>> [...]
> 
> +1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
> 

Re: [DISCUSS] NPM Package Deprecation

[Jesse]

Where did this land?

So, agreed, you did not say to deprecate minor, I meant to say we should
not deprecate any minor OR patch ...
If someone has an issue with a patch, the solution is always just to move
forward to the latest patch ... there is no 'support' expectation
Patching a patch would never make sense anyway, the patch version would
always get bumped anyway, so I see no need to deprecate patches.

I also think we should be careful when we talk about 'support', or what 'we
support'. We do not have a service level agreement, or any support
contract, we do what we can with the time that we have ... To this reality,
strictly stating what we will or won't support does not make a ton of sense
to me.  If someone sends a pr to backport a bug fix to a previous (implied
deprecated) version, we would probably just go and release it, because
someone wanted it ... and went and did it.

I am good with deprecating the packages you listed, in the case of `Cordova
CLI 0.0.1`, it is equivalent to deprecating cordova@0.x


On Tue, Aug 18, 2020 at 6:56 PM Bryan Ellis  wrote:

> >> I think this stance is too aggressive.
> >> For minor version bumps there is no need to deprecate the previous minor
> >> as any support request should be met with ‘update’
>
> I also did not say to deprecate a minor.
>
> > When releasing a minor, nothing happens.
>
> Minors are typically just a new feature release. We should be able to
> support the existing minor and new minor. The only difference is one gets a
> new feature or not.
>
> I think deprecating at the patch level is the most important rule. For
> example, if 1.0.1 is released, 1.0.0 should be deprecated. Patches, for the
> most part, should contain only bug and security fixes. Users should upgrade
> the patches to avoid bugs or security issues.
>
> >> For major versions, the fact that a new major is released should not be
> >> the defining factor, we cannot expect everyone to be able to immediately
> >> jump on a new version. In a dependency ridden world there is never a
> >> guarantee developers can even update.
>
> I have mentioned the idea of supporting the current release and one
> previous major, like the node project, in the past but it seems most people
> are in favor of only supporting the current major.
> Most do not want to back-port changes to a previous release.
>
> I was saying to deprecate past major when a new major is released only
> based on the information that most were in favor of only supporting the
> current.
>
> Anyways, I am OK if we support the current major and one past version.
>
> For Example:
> Cordova 9
> Cordova 10
>
> But I think we should not be supporting & should officially deprecate the
> packages for
> Cordova CLI 0.0.1
> Cordova CLI 1.x
> Cordova CLI 2.x
> …
> Cordova CLI 8.x
>
> And so on for the other packages, we also have.
>
>
> > On Aug 19, 2020, at 10:30, Chris Brody  wrote:
> >
> > For minor version bumps I had meant not deprecating the previous minor
> > version but only supporting 1-2 minor versions back. But my recollection
> is
> > that we generally have not published so many minor version updates
> between
> > the most recent major versions, so this may be pretty meaningless.
> >
> > I would agree that this is a bit aggressive. I had even proposed an idea
> of
> > extended LTS support in the past:
> > https://github.com/apache/cordova-discuss/issues/39
> >
> > Over the past couple of years I have seen issues pile up and take longer
> > than desired to be resolved. Here is a very unfortunate example:
> > https://github.com/apache/cordova-ios/issues/764
> >
> > My impression is that almost all maintainers are overworked volunteers,
> and
> > that new features and even sometimes breaking changes are needed to keep
> up
> > with the ever-changing platform landscape.
> >
> >
> > On Tue, Aug 18, 2020 at 12:47 PM Jesse  wrote:
> >
> >> I think this stance is too aggressive.
> >>
> >> For minor version bumps there is no need to deprecate the previous minor
> >> as any support request should be met with ‘update’
> >>
> >> For major versions, the fact that a new major is released should not be
> >> the defining factor, we cannot expect everyone to be able to immediately
> >> jump on a new version. In a dependency ridden world there is never a
> >> guarantee developers can even update.
> >>
> >> I think we should look at other major projects ( node itself even ) for
> >> inspiration.
> >> Ignore odd/even majors, I suggest reading thru
> >> h

Re: Cordova Committer Video Chat

[Jesse]

So far the times where we have all 6 are:

Tuesday Aug 25th
8AM OR 9AM
Wednesday, Aug 26
9AM
Thursday, Aug 27
8AM, 9AM

All times PDT
My preference would be for one of the Thursday slots, as my Wednesday is
already filling up.
Should I start another doodle with just the 5 dates that all 6 can attend.



On Mon, Aug 17, 2020 at 10:44 AM Jesse  wrote:

> Thanks Chris,
> Yes, that is the intent. All are welcome, but the agenda will be
> defined by pmc.
> I would like us to evolve this into a regular occurrence so we can show
> our work a little more widely.
>
> Cheers,
>   Jesse
>
>
> On Mon, Aug 17, 2020 at 10:37 AM Chris Brody 
> wrote:
>
>> My understanding from private correspondence is that this is open for
>> anyone to join or listen into (Jesse can you clarify?) and join the poll
>> on
>> Doodle, priority is of course a little higher for committers & PMC
>> members.
>>
>> Thanks Jesse for organizing this, much needed!
>>
>> On Mon, Aug 17, 2020 at 1:15 PM Jesse  wrote:
>>
>> > Hey all,
>> >
>> > I started a doodle to find the best time for us to meet.  Please enter
>> your
>> > preferences, you should be able to see all choices in your timezone.
>> >
>> > https://doodle.com/poll/huw5d8eemh83gim5
>> >
>> > Cheers,
>> >   Jesse
>> >
>>
>

Re: Cordova Committer Video Chat

[Jesse]

Okay, not sure if doodle notifies y'all but I closed it with the 8AM
Thursday August 27 (PST) option.
Thanks to Bryan Ellis for agreeing to sign on at midnight his time.

I don't have a formal.agenda, I think it would be good to just connect,
chat and catch up.
If you like, please feel free to add discussion topics to this thread and
we can try to cover them.

I would also like to make this a more regular occurrence, even weekly if we
can find a time(s) that work, possibly rotating so we all feel the pain a
little ...

I will share a google hangout via slack privately with #pmc so we all get
speaking slots in the hangout, before opening it up to youtube.

Also, please remember that we cannot discuss any security/exploit issues in
a public forum.  Should the need arise, these issues should be discussed on
the private mailing list.

Cheers,
  Jesse

On Mon, Aug 24, 2020 at 1:06 AM Niklas Merz  wrote:

> Thursday would be perfect for me. Another Doodle is fine too.
>
> August 24, 2020 8:18 AM, "Jesse"  wrote:
>
> > So far the times where we have all 6 are:
> >
> > Tuesday Aug 25th
> > 8AM OR 9AM
> > Wednesday, Aug 26
> > 9AM
> > Thursday, Aug 27
> > 8AM, 9AM
> >
> > All times PDT
> > My preference would be for one of the Thursday slots, as my Wednesday is
> > already filling up.
> > Should I start another doodle with just the 5 dates that all 6 can
> attend.
> >
> > On Mon, Aug 17, 2020 at 10:44 AM Jesse  wrote:
> >
> >> Thanks Chris,
> >> Yes, that is the intent. All are welcome, but the agenda will be
> >> defined by pmc.
> >> I would like us to evolve this into a regular occurrence so we can show
> >> our work a little more widely.
> >>
> >> Cheers,
> >> Jesse
> >>
> >> On Mon, Aug 17, 2020 at 10:37 AM Chris Brody 
> >> wrote:
> >>
> >>> My understanding from private correspondence is that this is open for
> >>> anyone to join or listen into (Jesse can you clarify?) and join the
> poll
> >>> on
> >>> Doodle, priority is of course a little higher for committers & PMC
> >>> members.
> >>>
> >>> Thanks Jesse for organizing this, much needed!
> >>>
> >>> On Mon, Aug 17, 2020 at 1:15 PM Jesse  wrote:
> >>>
> >>>> Hey all,
> >>>>
> >>>> I started a doodle to find the best time for us to meet. Please enter
> >>> your
> >>>> preferences, you should be able to see all choices in your timezone.
> >>>>
> >>>> https://doodle.com/poll/huw5d8eemh83gim5
> >>>>
> >>>> Cheers,
> >>>> Jesse
> >>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: PhoneGap Plugins?

[Jesse]

Thanks Simon

We'll look at this. Erisu appears to already be actively working on
havesource/cordova-plugin-push

Cheers,
  Jesse

On Fri, Aug 28, 2020 at 1:22 PM Simon MacDonald 
wrote:

> Hi folks,
>
> Long time no chat. As you are no doubt aware Adobe announced they are
> no longer in the PhoneGap business. To that end I archived the
> following plugins that are still being used widely:
>
> phonegap-plugin-push - 7,659 weekly downloads
> phonegap-plugin-barcodescanner - 11,058 weekly downloads
>
> I'm terribly disappointed that I have not been able to actively
> maintain them for the past two years. To that end, if you think it
> would be beneficial to Apache Cordova I can navigate the waters
> internally to donate the plugins to Apache.
>
> Note: I'm not trying to throw this code over the wall and make it
> someone else's problem. Cordova has been a positive experience in my
> life and if donating the code helps the project I'll make it happen.
> If you don't feel like it would help we'll keep the repo's archived
> and hope the community forks and maintains things.
>
> Julio mentioned there is already a fork of the push plugin at
> https://github.com/havesource/cordova-plugin-push.
>
> Let me know what you think as I've been contacted by a few users already.
>
> Simon Mac Donald
> http://simonmacdonald.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Greenfield for cordova-plugin-network-information + release version 3.0.0

[Jesse]

Welcome Pieter,

The best proposals are pull-requests. 
All your suggestions sound perfectly reasonable, and I personally would love to 
see this happen. 

Cheers,
  Jesse

> On Sep 6, 2020, at 3:38 PM, Niklas Merz  wrote:
> 
> Hi Pieter
> 
> At first a warm welcome to the list.
> 
> If you would like to open a proposal for discussion I can point you to
> the cordova-discuss repository:
> https://github.com/apache/cordova-discuss/ . We track some proposals in
> issues and pull requests there.
> 
> I am not really familiar with the plugin but looking at the description
> and recent activity it looks like it was designed to implement the old
> version of the Network Information API. Other community members probably
> know more about that.
> 
> A new major version could possibly change that if we can get consensus
> about this but someone would need to do the work.
> 
> It looks you already got your own requirements ready and I personally
> would build and publish this plugin myself in this case. Creating
> plugins is not that hard if you start with the skeleton of an existing
> one. Contact me if you need any help.
> 
> Kind regards
> Niklas
> 
>> Am 07.09.20 um 00:06 schrieb Pieter Van Poyer:
>> Hey Cordova devs
>> 
>> You are doing a great job with Cordova.
>> I've got a question, suggestion for the cordova-plugin-network-information.
>> 
>> Is it possible to open an issue, a milestone, a metaticket or something to 
>> discuss the future requirements of the plugin (v4).
>> Something like a whitepaper.
>> 
>> 
>> My suggestions for a whitepaper are:
>> 
>> Loosen the requirements of the plugin to it's barebone's essentials.
>> Requirements
>> 
>>  *   Detect online/offline only when the app is active.
>>  *   When online, only detect following types: WIFI, MOBILE
>> Stop with next requirements
>> 
>>  *   Detect online/offline when the app is not active.
>>  *   Don't try to detect other network type's beside WIFI and MOBILE.
>>  *   Do not let this plugin support background work like fileupload's and 
>> datasyncs. Remove it from the doc's.
>>  *   Drop Windows platform support.
>> For android: use the 
>> NetworkCallback<https://developer.android.com/reference/android/net/ConnectivityManager.NetworkCallback.html>
>>  API instead of the deprecated Connectivitymanager.
>> 
>> Maybe we could take some insparation by looking at the Capacitor plugin 
>> https://github.com/ionic-team/capacitor-plugins/tree/main/network or Flutter 
>> plugin.
>> 
>> 
>> Is it also possible to release version 3.0.0 of the plugin.
>> 
>> Kind regards
>> 
>> Pieter Van Poyer
>> 
>> 
>> 
>> Deze e-mail en alle gekoppelde bestanden zijn officiele documenten van 
>> Havenbedrijf Antwerpen NV van publiek recht en kunnen vertrouwelijke of 
>> persoonlijke informatie bevatten. Gelieve de afzender onmiddellijk via 
>> e-mail of telefonisch te verwittigen als u deze e-mail per vergissing heeft 
>> ontvangen en verwijder vervolgens de e-mail zonder deze te lezen, te 
>> reproduceren, te verspreiden of te ontsluiten naar derden. Havenbedrijf 
>> Antwerpen NV van publiek recht is op geen enkele manier verantwoordelijk 
>> voor fouten of onnauwkeurigheden in de inhoud van deze e-mail. Havenbedrijf 
>> Antwerpen NV van publiek recht kan niet aansprakelijk gesteld worden voor 
>> directe of indirecte schade, verlies of ongemak veroorzaakt als gevolg van 
>> een onnauwkeurigheid of fout in deze e-mail.
>> 
>> English Translation: This e-mail and all attached files are official 
>> documents of Antwerp Port Authority and may contain confidential or personal 
>> information. If you have received this e-mail in error, you are asked to 
>> inform the sender by e-mail or telephone immediately, and to remove it from 
>> your system without reading or reproducing it or passing it on to other 
>> parties. Antwerp Port Authority is in no way responsible for any errors or 
>> inaccuracies in the contents of this e-mail, nor can it be held liable for 
>> any direct or indirect loss, damage or inconvenience arising from any such 
>> errors or inaccuracies.
>> 
> 
> -
> 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: Cordova9 White Screen

[Jesse]

Hello Zhen,

This list is for talking about the development of Apache cordova project,
not for asking questions about its use, or getting help with issues in your
application.

I suggest you look through stack-overflow and post your question there.
Additionally, you can ask for help from other developers on the cordova
slack channel.

http://slack.cordova.io/

Cheers,
  Jesse



On Sun, Sep 6, 2020 at 9:48 PM cbd_zhenming...@cn.fujitsu.com <
cbd_zhenming...@cn.fujitsu.com> wrote:

> Hello Cordova:
>  How to solve the white screen problem of cordova9 packaged Android
> project (can't lower the cordova version)?
>  Thanks
>  zhen
>
>
>
>

Draft board report

[Jesse]

The quarterly board report draft is here:
https://github.com/apache/cordova-apache-board-reports/pull/11

Comments, additions, suggestions welcome.

Cheers,
  Jesse

Re: Draft board report

[Jesse]

Thanks Chris,

I added a blurb,  Report has been posted.
Sorry for the short turn around on this one,

Cheers,
  Jesse

On Wed, Sep 9, 2020 at 10:30 PM Chris Brody  wrote:

> I think we should include a note that there is a donation and there is
> ongoing discussion what to do with it.
>
>
> On Wed, Sep 9, 2020 at 11:17 PM Jesse  wrote:
>
> > The quarterly board report draft is here:
> > https://github.com/apache/cordova-apache-board-reports/pull/11
> >
> > Comments, additions, suggestions welcome.
> >
> > Cheers,
> >   Jesse
> >
>

[Discuss] Cordova Hangout NewEra#2

[Jesse]

As alluded to in the private conversations in #slack, we are tentatively
having a meetup on Thursday the 17th at 8 AM PDT.  This timeframe does not
work great for everyone, but none ever will, and I think that is okay, we
are distributed, and these meetings are about discussion and collaboration
more than decision making so no one should feel left out, or obligated to
attend.

That said, we haven't got a lot of time before Thursday morning ... ~30
hours, and I would like us to have some defined discussion points, ideally
brought up by people who would like to present them.

How does everyone feel about going ahead with the hangout this week? We
could also push back a week.
Who has a topic they would like to present for discussion?

Cheers,
  Jesse

Re: [Discuss] Cordova Hangout NewEra#2

[Jesse]

Okay, sounds like we have enough interest to go ahead with the Thursday
call.

Topics so far:
- Tim: putting that generous donation to use
- Darryl: issues with platform-centric workflow ( I can help by providing
some historical context )

Any other topics?

Cheers,
  Jesse


On Wed, Sep 16, 2020 at 7:14 AM Darryl Pogue  wrote:

> Tomorrow works for me.
>
> I think one topic that might be good to cover is the history of the
> Platform Centric Workflow, and the current problems with it, so that
> folks have some more context for discussions about potentially
> removing it. I'm happy to present this, but might need some
> input/corrections from Jesse about historical decisions.
>
> ~Darryl
>
> On Wed, Sep 16, 2020 at 1:38 AM Jesse  wrote:
> >
> > As alluded to in the private conversations in #slack, we are tentatively
> > having a meetup on Thursday the 17th at 8 AM PDT.  This timeframe does
> not
> > work great for everyone, but none ever will, and I think that is okay, we
> > are distributed, and these meetings are about discussion and
> collaboration
> > more than decision making so no one should feel left out, or obligated to
> > attend.
> >
> > That said, we haven't got a lot of time before Thursday morning ... ~30
> > hours, and I would like us to have some defined discussion points,
> ideally
> > brought up by people who would like to present them.
> >
> > How does everyone feel about going ahead with the hangout this week? We
> > could also push back a week.
> > Who has a topic they would like to present for discussion?
> >
> > Cheers,
> >   Jesse
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [VOTE] Camera Plugin Release

[Jesse]

+1

- coho verify-archive
- created project (ios) added plugin and built+ran
- code/repo changes review


On Sun, Sep 13, 2020 at 11:38 PM Niklas Merz  wrote:

> I vote +1
>
> I checked
> * signature and hash ok
> * no audit issues
> * license and notice exist
> * CI for Android and iOS green
> * local tests green
> * license headers ok
>
> Am 14.09.20 um 05:39 schrieb Bryan Ellis:
> > Please review and vote on this Cordova Plugin Camera Release v5.0.0
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The archive has been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/camera-20200914
> >
> > The package was published from its corresponding git tag:
> > cordova-plugin-camera: 5.0.0 (4584f15d9f)
> >
> > 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 the npm audit report was sufficient for release
> >
> > * AS the CI builds for ALL plugins are having issue in general, I
> manually tested:
> >   * Build Mobile Spec project for iOS & Android w/ CLI
> >   * Run Mobile Spec project on iOS & Android simulator w/ CLI
> >   * Executed the Mobile Spec Jasmine tests on iOS & Android
> >
> > Audit Report:
> >
> > 0 vulnerabilities found
> >
> >
> >
> > -
> > 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
>
>

Hangout

[Jesse]

Hello Cordova,

Sorry all, I totally zoned out on the hangout schedule this week. I won’t be 
able to organize/attend. 
If anyone else is able to pull this together, please record and I will happily 
help to post the video. 

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

Security Advisory CVE-2020-11990

[Jesse]

We have resolved a security issue in the camera plugin that could have
affected certain Cordova (Android) applications.

CVE-2020-11990: Apache Cordova Plugin camera vulnerable to information
disclosure

Type of Vulnerability:

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Severity: Low

Vendor: The Apache Software Foundation

Possible attackers condition:

An attacker who can install (or lead the victim to install) the specially
crafted (or malicious) Android application. Android documentation describes
the external cache location as application specific, however, "There is no
security enforced with these files. For example, any application holding
Manifest.permission.WRITEEXTERNALSTORAGE can write to these files." ( and
thereby read )

Possible victims:

Android users that take pictures with an Apache Cordova based application
and attached removable storage.

Possible Impacts:

Confidentiality is breached.
The image file (photo) taken by the Android apps that was developed using
the Apache Cordova camera plugin will be disclosed.

Versions Affected:

Cordova Android applications using the Camera plugin

( cordova-plugin-camera version 4.1.0 and below )

Upgrade path:

Developers who are concerned about this issue should install version 5.0.0
or higher of cordova-plugin-camera

Mitigation Steps:

Upgrade plugin and rebuild application, update deployments.

Credit: JPCERT/CC Vulnerability Coordination Group. (JVN#59779918)

Re: Consultant services needed

[Jesse]

Not sure this would reach the original poster, the email address lists as 
.invalid

ReplyTo is set to dev.cordova for all messages on the list .. 

> On Dec 10, 2020, at 9:18 AM, Norman Breau  wrote:
> 
> This mailing list is for development discussion of Cordova only.
> 
> I'd suggest joining the Slack community at http://slack.cordova.io/ and 
> posting in the #jobs channel for job related posts.
> Thank you for your cooperation.
> Norman Breau
> Software Developer
> 
> nor...@nbsolutions.ca (mailto:nor...@nbsolutions.ca)
> https://breautek.com
> 
>> On Dec 8 2020, at 11:03 pm, Andrew Silber  
>> wrote:
>> Hello,
>> I am considering Cordova as a technology solution for a project for a games 
>> company to deploy games built in Cocos Creator (that is, all inside HTML5 
>> canvas). I would like to find a company which can provide some support such 
>> that if we have questions or run into problems, said company could help 
>> unblock us.
>> Can anyone recommend a company which could provide such premium services?
>> Thanks much,Andrew
>> 
> 

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

Re: SSH connect Plugin for IOS

[Jesse]

Hello Rutuja,

This mailing list is for discussion of developing cordova itself, and not
how to develop apps with cordova.  The plugin you reference does state that
it only supports cordova-android, so I wonder what was working in
cordova-ios before 6.0?  Ultimately you should ask this question on stack
overflow, or via our slack community where developers (and committers)
collaborate and share advice on how to develop apps with cordova. You could
also contact the developer of that plugin, and ask them if they intend to
support cordova-ios.

Cheers,
  Jesse

http://slack.cordova.io/
https://stackoverflow.com/questions/tagged/cordova




On Mon, Dec 28, 2020 at 11:15 PM Ashok Chavan, Rutuja
 wrote:

> Hi Team,
>
> We have built a cordova app which earlier was using corodva-plugin-SSH to
> connect to SFT to transfer files there.
>
> However recently when we upgraded the IOS platform to 6.0.0 we are facing
> issues while running the app. After the splash screen just a white screen
> appears. We suspect this to be an issue with this plugin as we checked on
> internet and found that this plugin is only supported for Android now.
>
> Can you please suggest a alternate plugin which we can use for IOS to
> connect to SFT? We have checked for cordova-sftp-plugin but as per the
> known issues mentioned in GIT the upload functionality is not working for
> IOS yet.
>
> Regards,
> Rutuja Chavan
> Global Apps & ERP Platform - FIORI
> Accenture - PDC
> Mail: rutuja.ashok.cha...@accenture.com rutuja.ashok.cha...@accenture.com>
> Contact: +91 9922430367
>
>
> 
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited. Where allowed
> by local law, electronic communications with Accenture and its affiliates,
> including e-mail and instant messaging (including content), may be scanned
> by our systems for the purposes of information security and assessment of
> internal compliance with Accenture policy. Your privacy is important to us.
> Accenture uses your personal data only in compliance with data protection
> laws. For further information on how Accenture processes your personal
> data, please see our privacy statement at
> https://www.accenture.com/us-en/privacy-policy.
>
> __
>
> www.accenture.com
>

Re: [VOTE] Deprecate cordova-plugin-wkwebview-engine

[Jesse]

+1

> On Feb 5, 2021, at 5:49 PM, Norman Breau  wrote:
> 
> Now that the wkwebview engine plugin is published on NPM, pending 
> announcement (waiting for cordova.apache.org to update with the blog post). I 
> would like to set motion a vote to deprecate this package.
> 
> The reason for deprecation is the plugin's code base has effectively been 
> moved to the core cordova-ios platform, making the plugin deprecated.
> 
> Upon a successful vote to deprecate this plugin, I'll prepare a PR adding 
> deprecation text to the plugin's readme as well as marking the NPM package as 
> deprecated.
> 
> I vote +1.
> 
> 
> 
> -
> 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

March Board Repor

[Jesse]

Committed the March board report here, I'll submit in the morning.
Let me know if there is anything to add.

https://github.com/apache/cordova-apache-board-reports/blob/master/2021/2021-03.md

Re: cordova

[Jesse]

Hi Illias,

This email list is for developers working on cordova, and not developers
using cordova.
For support, please ask your question either in our slack community (
http://slack.cordova.io/ ), or on stack-overflow ( https://stackoverflow
.com/questions/tagged/cordova )where many questions are answered.

Cheers,
  Jesse


On Mon, Mar 29, 2021 at 10:28 AM Ilias M  wrote:

> Hello,
> I updated the android version of an app that was 5.0.1 to android 9 with
> target sdk 28.
> The application didn't ask me for file storage permission and didn't
> start. My manifest has the WRITE_EXTERNAL_STORAGE
> permission. Then I noticed that the file and media permission was declined.
>
>

Re: [DISCUSS] cordova-android 9.1.0 Minor Release

[Jesse]

+1 to moving ahead with 9.1.0, I think this is correctly identified as a
minor.


On Tue, Mar 30, 2021 at 2:51 PM  wrote:

> It would be great if we could include
> https://github.com/apache/cordova-android/pull/1101 in this release.
>
> It is just a pure refactoring/non-functional change PR but it sure would be
> great to merge and release it before it gets stale.
>
> I would have no concerns merging it as is, even without reviews, since I am
> confident it is an improvement in code quality. So we would not need to
> delay the release.
>
> What do you think?
>
> Bryan Ellis  schrieb am Di., 30. März 2021, 17:06:
>
> > Does anyone have any reason to delay a cordova-android minor release
> > (9.1.0)?
> >
> > Any additional outstanding changes to land?
> >
> > If not, I will start the release process shortly.
> >
> >
> > ==Changes==
> >
> > https://github.com/apache/cordova-android/compare/9.0.0...master
>

June board report

[Jesse]

I have committed the June board report [1]
Please let me know if there is anything you would like added or amended, or
if I made any errors.
I will submit to the Apache board this evening.

Cheers,
  Jesse


[1]
https://github.com/apache/cordova-apache-board-reports/blob/master/2021/2021-06.md

Re: [Cordova dev] Task :app:stripDebugDebugSymbols / No version of NDK matched [...]

[Jesse]

Cordova has plenty of native code, users just don’t need to write any. 


> On Jul 13, 2021, at 5:27 AM, Norman Breau  wrote:
> 
> I don't think Cordova has any native code whatsoever, so I don't think this 
> is really relevant to Cordova.
> 
> This might be caused by a plugin that needs to compile/import native code, in 
> which case the solution seems to be to install version 21.0.6113669 instead 
> of 22.1.7171670. If this is the case, it would be up to the user (or the 
> plugin author, if they decide to take responsibility) to ensure that the 
> environment is configured in a way that it will work with that plugin.
> 
>> On 2021-07-12 11:45 p.m., Chris Brody wrote:
>> Hello I just encountered this after having reinstalled my system on macOS,
>> installing recent NDK via Android Studio:
>> 
>> Starting a Gradle Daemon (subsequent builds will be faster)
>> 
>> *> Task :app:stripDebugDebugSymbols* FAILED
>> 
>> 
>> FAILURE: Build failed with an exception.
>> 
>> 
>> * What went wrong:
>> 
>> Execution failed for task ':app:stripDebugDebugSymbols'.
>> 
>>> No version of NDK matched the requested version 21.0.6113669. Versions
>> available locally: 22.1.7171670
>> 
>> already found a couple of resources:
>> 
>>-
>>
>> https://stackoverflow.com/questions/60404457/no-version-of-ndk-matched-the-requested-version
>>- https://www.programmersought.com/article/38846032343/
>> 
>> I hope we can find a better solution. Here is what I get from React Native,
>> for example:
>> 
>> *> Task :app:stripDebugDebugSymbols*
>> 
>> Unable to strip the following libraries, packaging them as they are:
>> libc++_shared.so, libevent-2.1.so, libevent_core-2.1.so,
>> libevent_extra-2.1.so, libfb.so, libfbjni.so, libflipper.so,
>> libfolly_futures.so, libfolly_json.so, libglog.so, libglog_init.so,
>> libhermes-executor-common-debug.so, libhermes-executor-common-release.so,
>> libhermes-executor-debug.so, libhermes-executor-release.so,
>> libhermes-inspector.so, libimagepipeline.so, libjsc.so, libjscexecutor.so,
>> libjsijniprofiler.so, libjsinspector.so, libnative-filters.so,
>> libnative-imagetranscoder.so, libreact_codegen_reactandroidspec.so,
>> libreact_nativemodule_core.so, libreactnativeblob.so, libreactnativejni.so,
>> libreactnativeutilsjni.so, libreactperfloggerjni.so,
>> libturbomodulejsijni.so, libyoga.so.
>> 
> 
> -
> 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 dev] Task :app:stripDebugDebugSymbols / No version of NDK matched [...]

[Jesse]

Got it. Thanks. 

> On Jul 13, 2021, at 7:11 AM, julio cesar sanchez  
> wrote:
> 
> Jesse, Norman means NDK code, which is considered native (stands for Native
> Development Kit).
> We don't have any of those.
> We have plenty of java code, but that's not affected by the NDK.
> 
>> El mar, 13 jul 2021 a las 16:00, Norman Breau ()
>> escribió:
>> 
>> What Apache maintained plugin uses C/C++ code for android?
>> 
>>> On 2021-07-13 10:44 a.m., Jesse wrote:
>>> Cordova has plenty of native code, users just don’t need to write any.
>>> 
>>> 
>>>> On Jul 13, 2021, at 5:27 AM, Norman Breau 
>> wrote:
>>>> 
>>>> I don't think Cordova has any native code whatsoever, so I don't think
>> this is really relevant to Cordova.
>>>> 
>>>> This might be caused by a plugin that needs to compile/import native
>> code, in which case the solution seems to be to install version
>> 21.0.6113669 instead of 22.1.7171670. If this is the case, it would be up
>> to the user (or the plugin author, if they decide to take responsibility)
>> to ensure that the environment is configured in a way that it will work
>> with that plugin.
>>>> 
>>>>> On 2021-07-12 11:45 p.m., Chris Brody wrote:
>>>>> Hello I just encountered this after having reinstalled my system on
>> macOS,
>>>>> installing recent NDK via Android Studio:
>>>>> 
>>>>> Starting a Gradle Daemon (subsequent builds will be faster)
>>>>> 
>>>>> *> Task :app:stripDebugDebugSymbols* FAILED
>>>>> 
>>>>> 
>>>>> FAILURE: Build failed with an exception.
>>>>> 
>>>>> 
>>>>> * What went wrong:
>>>>> 
>>>>> Execution failed for task ':app:stripDebugDebugSymbols'.
>>>>> 
>>>>>> No version of NDK matched the requested version 21.0.6113669. Versions
>>>>> available locally: 22.1.7171670
>>>>> 
>>>>> already found a couple of resources:
>>>>> 
>>>>>-
>>>>> 
>> https://stackoverflow.com/questions/60404457/no-version-of-ndk-matched-the-requested-version
>>>>>- https://www.programmersought.com/article/38846032343/
>>>>> 
>>>>> I hope we can find a better solution. Here is what I get from React
>> Native,
>>>>> for example:
>>>>> 
>>>>> *> Task :app:stripDebugDebugSymbols*
>>>>> 
>>>>> Unable to strip the following libraries, packaging them as they are:
>>>>> libc++_shared.so, libevent-2.1.so, libevent_core-2.1.so,
>>>>> libevent_extra-2.1.so, libfb.so, libfbjni.so, libflipper.so,
>>>>> libfolly_futures.so, libfolly_json.so, libglog.so, libglog_init.so,
>>>>> libhermes-executor-common-debug.so,
>> libhermes-executor-common-release.so,
>>>>> libhermes-executor-debug.so, libhermes-executor-release.so,
>>>>> libhermes-inspector.so, libimagepipeline.so, libjsc.so,
>> libjscexecutor.so,
>>>>> libjsijniprofiler.so, libjsinspector.so, libnative-filters.so,
>>>>> libnative-imagetranscoder.so, libreact_codegen_reactandroidspec.so,
>>>>> libreact_nativemodule_core.so, libreactnativeblob.so,
>> libreactnativejni.so,
>>>>> libreactnativeutilsjni.so, libreactperfloggerjni.so,
>>>>> libturbomodulejsijni.so, libyoga.so.
>>>>> 
>>>> -
>>>> 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

September board report

[Jesse]

Draft is in this pr:
https://github.com/apache/cordova-apache-board-reports/pull/14

If there are no issues/additions I will be submitting this tomorrow.

Cheers,
  Jesse

Re: Using npmrc

[Jesse]

Go for it!

> On Sep 11, 2021, at 6:19 PM, Darryl Pogue  wrote:
> 
> +1 from me
> 
>> On Sat, Sep 11, 2021 at 6:16 PM Norman Breau  wrote:
>> 
>> Hi all,
>> 
>> I propose that we start adding a .npmrc file to all of our repos. We
>> only need one setting configured: registry=https://registry.npmjs.org
>> 
>> https://registry.npmjs.org is the default value, but this will ensure
>> that while in cordova repos, NPM will use the official NPM registry. For
>> some people who have different environments (like me...), it's easy to
>> run into situations such as
>> https://github.com/apache/cordova-lib/pull/879#pullrequestreview-751998001
>> (Thanks Nik for thoroughly review, even for something that seemed to
>> simple!).
>> 
>> This is a simple proposal, but I wanted to ensure the community had no
>> objections before I start forking and making PRs on all the repos.
>> 
>> Cheers!
>> 
>> 
>> -
>> 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: [VOTE] cordova-eslint 4.0.0 & cordova-app-hello-world 6.0.0 Major Release

[Jesse]

+1

- ran coho verify-archive
- review of commits
- CI green


On Wed, Oct 27, 2021 at 4:55 AM Bryan Ellis  wrote:

> Please review and vote on the following packages for release by replying
> to this email (and keep discussion on the DISCUSS thread):
>
> - cordova-eslint v4.0.0
> - cordova-app-hello-world v6.0.0
>
> The archives has been published to the dist/dev:
>
> - https://dist.apache.org/repos/dist/dev/cordova/eslint-v4.0.0/ <
> https://dist.apache.org/repos/dist/dev/cordova/eslint-v4.0.0/>
> - https://dist.apache.org/repos/dist/dev/cordova/app-hello-world-6.0.0/ <
> https://dist.apache.org/repos/dist/dev/cordova/app-hello-world-6.0.0/>
>
> The packages was published from its corresponding git tag:
>
> cordova-eslint: 4.0.0 (d0f055c8f8)
> cordova-app-hello-world: 6.0.0 (8430b5cfe9)
>
> 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 the continuous build was green when repo was tagged
> * Ran `npm test`
> * Ran `npm audit`
> * Ran `cordova create`

Re: Targeted donation for testing devices for Cordova project

[Jesse]

Thanks Craig. 

I started a vote, (on private) to nominate purchasers. I will start another 
shortly to include price limits, I have ball-parked them in USD already, but 
each purchaser will need to check availability and get more accurate numbers, 
plus shipping, in their locale. 


Cheers,
  Jesse

> On Oct 30, 2021, at 2:25 PM, Craig Russell  wrote:
> 
> Hi Jesse,
> 
> After talking to Myrle, our Treasurer, I suggest a small change to the 
> proposed process.
> 
> The Cordova PMC still needs to identify names, apache ids, and maximum spend 
> for each item.
> 
> But Treasury also need a person (coordinator) who will take responsibility 
> for actually issuing the cards for each purchaser. This will require that 
> person to log into the Ramp system, fill a small form, and then send the 
> credit card information to the purchasers. Training on the Ramp system should 
> take about 10 minutes via a Zoom call with me. Actually issuing the card 
> should take the coordinator about 5 minutes for each card issued.
> 
> I'm looking forward to working with you on the details. For now, a vote to 
> approve the names, apache ids, maximum spend per purchaser, and coordinator 
> will get the ball rolling on this.
> 
> Warm regards,
> Craig
> 
>> On Oct 29, 2021, at 4:27 PM, Craig Russell  wrote:
>> 
>> Hi Jess,
>> 
>> I'm taking point on this from the fundraising/treasurer perspective. 
>> 
>> Once you provide me with the names, apache ids, and maximum spend for each 
>> of the items, I will issue bespoke Ramp credit cards for the purchases, one 
>> for each of the purchasers. I will then send the details of the credit cards 
>> to the apache address of the purchasers.
>> 
>> I will need the maximum spend including taxes, shipping, and handling for 
>> each of the purchasers. After they complete the purchase we will need the 
>> itemized receipt for each of the items. The receipt should be sent to 
>> t...@treasurer.apache.org with cc to priv...@cordova.apache.org . [The 
>> receipt is needed for ASF records.]
>> 
>> Let's get the Cordova team what is needed.
>> 
>> Warm regards,
>> Craig
>> 
>>> Hi Daniel,
>>> 
>>> Here is the list of test devices as it stands, including estimated price, 
>>> and location of the requestor.
>>> 
>>> Julio Cesar, Spain
>>>   - Google Pixel 5 unlocked ~ $700 USD
>>> Tim Brust, Germany
>>>   - Google Pixel 5 unlocked - $700 USD
>>> Bryan Ellis, Japan
>>>   - iPad ~ $350 USD
>>> Daryll Pogue, Canada
>>>   - iPad Mini ~ $400 USD
>>> Jesse MacFadyen, Canada
>>>   - Galaxy Tab A ~ $250 USD
>>> 
>>> All the listed committers are currently active in the project.  The device 
>>> list represents a variety of hardware / screen-size configurations so I 
>>> expect us all to be able to test things for each other.
>>> I have not looked into the MacInCloud service, or how this would work for 
>>> the team, here are their listed plans [1]
>>> Amazon's EC2 service [2] might be a better option given that I see AWS 
>>> credits listed as a donation usable item [3]
>>> 
>>> There is also a question around whether it makes sense for committers to 
>>> request specific hardware for development.  Future features in Mac/iOS dev 
>>> specifically require Apple silicon for dev/testing.  This is easiest to 
>>> achieve with a Mac-mini M1 which costs around $700 USD [4].  Is this an 
>>> allowed use of donated funds?
>>> 
>>> Next discussion I guess will be logistics. How do we go about purchasing 
>>> and distributing devices around the world?  We can maintain the list of who 
>>> has what and where with contact info.
>>> Thanks for your patience in working through all of this with us.
>>> 
>>> Cheers,
>>> Jesse
>>> 
>> 
>> Craig L Russell
>> c...@apache.org
>> 
> 
> Craig L Russell
> c...@apache.org
> 

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

Re: [VOTE] Statusbar Plugin 3.0.0 Release (2021/11/25)

[Jesse]

+1

- coho verify archive
- code review
- created app and installed without issue

On Fri, Nov 26, 2021 at 7:57 AM Niklas Merz  wrote:

> I vote +1
>
> I checked:
>
> * signature and hash
> * cordovaDependency in package.json
> * license and notice
> * tests pass
> * tag hash matches
> * run new app with plugin
>
> On November 25, 2021, Erisu  wrote:
> > Please review and vote on this Cordova Plugin Statusbar Release v3.0.0
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The archive has been published to dist/dev:
> >
> >  https://dist.apache.org/repos/dist/dev/cordova/statusbar-v3.0.0
> >
> > The package was published from its corresponding git tag:
> >
> >  cordova-plugin-statusbar: 3.0.0 (49bb5ec69e)
> >
> > 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 the npm audit report was sufficient for release
> >
> > * AS there are issues within the CI testing service accross ALL
> > plugins, for this release I have manually tested:
> >  * Build Mobile Spec project for iOS & Android w/ CLI
> >  * Run Mobile Spec project on iOS & Android simulator w/ CLI
> >  * Executed the Mobile Spec Jasmine tests on iOS & Android
> >
> > Audit Report:
> >
> >  0 vulnerabilities found
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
>

Re: [VOTE] cordova-create 4.0.0 Release

[Jesse]

+1

- coho verify-archive
- build was green when repo was tagged
- npm test
- created a project

On Mon, Nov 29, 2021 at 6:55 PM Bryan Ellis  wrote:

> Please review and vote on this cordova-create release v4.0.0
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> The archive has been published to dist/dev:
>
>https://dist.apache.org/repos/dist/dev/cordova/create-4.0.0
>
> The package was published from its corresponding git tag:
>
> cordova-create: 4.0.0 (fdc45add31)
>
> 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 the continuous build was green when repo was tagged
> * Ran `npm test`
> * Ran `npm audit`
>
>There is one moderate severity report, but this will require a
> cordova-fetch update & release.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [dongourdet/cordova-plugin-camera] PR run failed: Android Testsuite, Attempt #2 - (android) catch RecoverableSecurityException (fa95703)

[Jesse]

I am assuming it is this pr =>
https://github.com/apache/cordova-plugin-camera/pull/781

On Thu, Dec 2, 2021 at 4:49 PM Don Gourdet  wrote:

> Hi cordova dev team,
> Can you please review my pull request?
> Note: I am having problems with running the unit tests.
> It seems to fail at:
>
> Android project created with cordova-android@10.1.1
> Installing "cordova-plugin-camera" for android
> Subproject Path: CordovaLib
> Subproject Path: app
> Installing "cordova-plugin-camera-tests" for android
> Installing "cordova-plugin-paramedic" for android
> Failed to install 'cordova-plugin-paramedic': Error: There was a conflict
> trying to modify attributes with  in plugin
> cordova-plugin-paramedic. The conflicting plugin, undefined, already
> modified the same attributes. The conflict must be resolved before
> cordova-plugin-paramedic can be added. You may use --force to add the
> plugin and overwrite the conflicting attributes.
>
>
> -- Forwarded message -
> From: Don Gourdet 
> Date: Thu, Dec 2, 2021 at 8:26 AM
> Subject: [dongourdet/cordova-plugin-camera] PR run failed: Android
> Testsuite, Attempt #2 - (android) catch RecoverableSecurityException
> (fa95703)
> To: dongourdet/cordova-plugin-camera <
> cordova-plugin-cam...@noreply.github.com>
> Cc: Ci activity 
>
>
>
> [image: GitHub] [dongourdet/cordova-plugin-camera] Android Testsuite
> workflow run, Attempt #2
>
>   Android Testsuite, Attempt #2: Some jobs were not successful
>
> View workflow run
> <
> https://github.com/dongourdet/cordova-plugin-camera/actions/runs/1526371966
> >
>
> [image: Android 5.1 Test]
>
> *Android Testsuite, Attempt #2* / Android 5.1 Test
> Failed in 5 minutes and 5 seconds
> [image: annotations for Android Testsuite, Attempt #2 / Android 5.1 Test] 1
> <
> https://github.com/dongourdet/cordova-plugin-camera/actions/runs/1526371966
> >
> [image: Android 6 Test]
>
> *Android Testsuite, Attempt #2* / Android 6 Test
> Cancelled
> [image: annotations for Android Testsuite, Attempt #2 / Android 6 Test] 2
> <
> https://github.com/dongourdet/cordova-plugin-camera/actions/runs/1526371966
> >
> [image: Android 7 Test]
>
> *Android Testsuite, Attempt #2* / Android 7 Test
> Failed in 5 minutes and 12 seconds
> [image: annotations for Android Testsuite, Attempt #2 / Android 7 Test] 2
> <
> https://github.com/dongourdet/cordova-plugin-camera/actions/runs/1526371966
> >
> [image: Android 7.1 Test]
>
> *Android Testsuite, Attempt #2* / Android 7.1 Test
> Cancelled
> [image: annotations for Android Testsuite, Attempt #2 / Android 7.1 Test] 1
> <
> https://github.com/dongourdet/cordova-plugin-camera/actions/runs/1526371966
> >
> [image: Android 8 Test]
>
> *Android Testsuite, Attempt #2* / Android 8 Test
> Cancelled
> [image: annotations for Android Testsuite, Attempt #2 / Android 8 Test] 1
> <
> https://github.com/dongourdet/cordova-plugin-camera/actions/runs/1526371966
> >
> [image: Android 8.1 Test]
>
> *Android Testsuite, Attempt #2* / Android 8.1 Test
> Cancelled
> [image: annotations for Android Testsuite, Attempt #2 / Android 8.1 Test] 1
> <
> https://github.com/dongourdet/cordova-plugin-camera/actions/runs/1526371966
> >
> [image: Android 9 Test]
>
> *Android Testsuite, Attempt #2* / Android 9 Test
> Cancelled
> [image: annotations for Android Testsuite, Attempt #2 / Android 9 Test] 1
> <
> https://github.com/dongourdet/cordova-plugin-camera/actions/runs/1526371966
> >
> [image: Android 10 Test]
>
> *Android Testsuite, Attempt #2* / Android 10 Test
> Cancelled
> [image: annotations for Android Testsuite, Attempt #2 / Android 10 Test] 2
> <
> https://github.com/dongourdet/cordova-plugin-camera/actions/runs/1526371966
> >
> [image: Android 11 Test]
>
> *Android Testsuite, Attempt #2* / Android 11 Test
> Cancelled
> [image: annotations for Android Testsuite, Attempt #2 / Android 11 Test] 2
> <
> https://github.com/dongourdet/cordova-plugin-camera/actions/runs/1526371966
> >
>
>
>
> —
> You are receiving this because this workflow ran on your branch.
> Manage your GitHub Actions notifications
> 
>
>
> GitHub, Inc. ・88 Colin P Kelly Jr Street ・San Francisco, CA 94107
>
>
>
> --
> Kind Regards,
> Don A.S. Gourdet
> https://www.linkedin.com/in/dongourdet/en
>

Re: NPM Packages issue in cordova-electron

[Jesse]

This email list is for developers working on cordova, and not developers
using cordova.
For support, please ask your question either in our slack community (
http://slack.cordova.io/ ), or on stack-overflow (
https://stackoverflow.com/questions/tagged/cordova ) where many questions
are answered.

Cheers,
  Jesse

On Tue, Dec 7, 2021 at 2:07 PM Nair, Rahul  wrote:

> Hi,
>
>We have been using the Apache Cordova to develop a native
> windows application using the electron platform. We have run into an issue
> when we try to work with any NPM package in the Electron platform. On
> installing any NPM package in the cordova electron app, it works fine if we
> run the command "cordova run electron". The same doesn't work when we run
> the command "cordova build electron". It skips the installation of the
> dependencies mentioned in the package.json.
>
> Our project config and details:
>
>   *   cordova-electron: ^3.0.0
>   *   Cordova CLI version: 10.0.0
>
> Thanks & Regards,
> Rahul Nair
> M +91 - 99099 42544
> DXC Technology, 39/40 , HP Avenue,
> Electronic City, Hosur Road,
> Bangalore - 560 100
>
>
>
> DXC Technology India Private Limited - 9th Floor, Block-D Littlewood
> Tower, TRIL Info Park Ramanujan IT City, Rajiv Gandhi Salai, Taramani,
> Chennai - 600113. CIN: U72900TN2015FTC102489.
> DXC Technology Company -- This message is transmitted to you by or on
> behalf of DXC Technology Company or one of its affiliates. It is intended
> exclusively for the addressee. The substance of this message, along with
> any attachments, may contain proprietary, confidential or privileged
> information or information that is otherwise legally exempt from
> disclosure. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient of this message, you are
> not authorized to read, print, retain, copy or disseminate any part of this
> message. If you have received this message in error, please destroy and
> delete all copies and notify the sender by return e-mail. Regardless of
> content, this e-mail shall not operate to bind DXC Technology Company or
> any of its affiliates to any order or other contract unless pursuant to
> explicit written agreement or government initiative expressly permitting
> the use of e-mail for such purpose.
>

Its board report time again

[Jesse]

Here's a draft, please feel free to add/comment

https://github.com/apache/cordova-apache-board-reports/pull/15

Cheers,
  Jesse

Re: [VOTE] Cordova-OSX 7.0.0 Release

[Jesse]

+1

- coho verify-archive
- created a new project and added platform, ran successfully
- reviewed code changes
- ci green


On Tue, Mar 8, 2022 at 5:57 AM pieter van poyer 
wrote:

> I vote +1
> * blog post looks good
> * changes are looking good
>
> Kind regards
> Pieter
>
> Op zo 6 mrt. 2022 om 12:13 schreef Niklas Merz :
>
> > Please review and vote on this 7.0.0 OSX Release
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The archive has been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/osx-7.0.0/
> >
> > The package was published from its corresponding git tag:
> > cordova-osx: 7.0.0 (d96f2a68ec)
> >
> > Note that you can test it out via:
> >
> > cordova platform add https://github.com/apache/cordova-osx#7.0.0
> >
> > !! Please also review the announcement blog post where we should use the
> > opportunity to finally announce the platform deprecation and point users
> > to the alternatives electron and ios with Catalyst:
> > https://github.com/apache/cordova-docs/pull/1233
> >
> >
> > 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
> > * Ensured continuous build was green when repo was tagged
> > * Short tests that IAB and camera plugin are available in a new hello
> > world project
> > * Tests pass locally
> >
>

Re: [VOTE] Deprecate cordova-osx platform

[Jesse]

+1


> On Mar 12, 2022, at 3:22 PM, Norman Breau  wrote:
> 
> I vote +1
> 
>> On 2022-03-12 8:35 a.m., julio cesar sanchez wrote:
>> I vote +1
>> 
>> El El sáb, 12 mar 2022 a las 10:24, Niklas Merz 
>> escribió:
>> 
>>> As discussed for the latest release of osx and a few times before [1],
>>> we could officially deprecate the osx platform. It seems it does not
>>> have many users anymore and we can offer good alternatives with Catalyst
>>> in cordova-ios and cordova-electron. Version 7.0.0 of osx already has a
>>> deprecation notice in the announcement blog post [2].
>>> 
>>> I will follow this process: https://github.com/apache/cordova-
>>> contribute/blob/master/deprecation.md
>>> 
>>> I vote +1
>>> 
>>> [1] https://lists.apache.org/thread/lqq2xoy3pjqcyl052gv0qom2f31zgg8k
>>> [2] https://cordova.apache.org/announcements/2022/03/09/osx-release-
>>> 7.0.0.html
>>> 
> 
> -
> 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] New data privacy policy & analytics in CLI

[Jesse]


I’ll have a look at the switch to Matomo, hopefully it’s as easy as GA. 

> On Apr 23, 2022, at 2:47 AM, Niklas Merz  wrote:
> Hey folks,
> 
> I just had a closer look at the email regarding the new privacy policy
> (attached below). Adding the link is the easy part. Please check out the
> PR https://github.com/apache/cordova-docs/pull/1243
> 
> I am not aware of analytics for the website but we have the telemetry in
> the CLI. Do you think we should change something about this? I don't
> know much about these metrics so looking forward to your suggestions. 
> 
> I'm happy to help if changes are needed.
> 
> Regards
> Niklas
> 
> -- Forwarded message -
> From: Christian Grobmeier 
> Date: Thu, Apr 21, 2022 at 1:34 PM
> Subject: New data privacy policy - may impact your websites
> To: priv...@apache.org
> 
>> Dear PMCs,
>> 
>> The Apache Software Foundation takes privacy seriously and works
>> towards becoming compliant with the GDPR (the European Union's General
>> Data Protection Regulation). In this first step we are trying to make
>> publicly-visible websites and services GDPR compliant.
>> 
>> All websites run by the ASF must be compliant with the new website
>> privacy policy and add a link to it:
>> https://privacy.apache.org/policies/privacy-policy-public.html
>> 
>> Please remove all “custom” privacy policies.
>> 
>> For further changes we have established a FAQ:
>> https://privacy.apache.org/faq/committers.html
>> 
>> One of the biggest impacts might be the removal of Google Analytics.
>> Personally, I believe we should not track our visitors at all.
>> However, I understand the need to improve our websites. For that
>> reason volunteers have created a VM and installed Matomo as a Google
>> Analytics replacement.
>> 
>> You can look at Matomo here:
>> https://analytics.apache.org/
>> 
>> If you need to learn more about your users, you can ask for a site ID
>> and tracking code at priv...@apache.org and join Apache Flink, Apache
>> Shiro, Apache Maven and others.
>> 
>> Please note that we are still learning about the new system and will
>> add projects one by one.
>> 
>> We hope that all projects can link to the new privacy policy and
>> remove Google Analytics until 22nd of July 2022.
>> 
>> If you have any doubts or questions, or need help, please don’t
>> hesitate to ask. Also, if you have improvements or suggestions for the
>> public privacy policy - let us know.
>> 
>> You can reach out to priv...@apache.org (mailing list) or by replying
>> to me directly.
>> 
>> Kind regards,
>> Christian Grobmeier
>> 
>> --
>> The Apache Software Foundation
>> V.P., Data Privacy

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

Re: [DISCUSS] New data privacy policy & analytics in CLI

[Jesse]

Matomo is live, you can see traffic showing up here ...
https://analytics.apache.org/index.php?module=CoreHome&action=index&date=2022-04-27&period=day&idSite=16#?period=day&date=2022-04-27&idSite=16&category=Dashboard_Dashboard&subcategory=1

On Sat, Apr 23, 2022 at 9:39 AM Jesse  wrote:

>
> I’ll have a look at the switch to Matomo, hopefully it’s as easy as GA.
>
> > On Apr 23, 2022, at 2:47 AM, Niklas Merz  wrote:
> > Hey folks,
> >
> > I just had a closer look at the email regarding the new privacy policy
> > (attached below). Adding the link is the easy part. Please check out the
> > PR https://github.com/apache/cordova-docs/pull/1243
> >
> > I am not aware of analytics for the website but we have the telemetry in
> > the CLI. Do you think we should change something about this? I don't
> > know much about these metrics so looking forward to your suggestions.
> >
> > I'm happy to help if changes are needed.
> >
> > Regards
> > Niklas
> >
> > -- Forwarded message -
> > From: Christian Grobmeier 
> > Date: Thu, Apr 21, 2022 at 1:34 PM
> > Subject: New data privacy policy - may impact your websites
> > To: priv...@apache.org
> >
> >> Dear PMCs,
> >>
> >> The Apache Software Foundation takes privacy seriously and works
> >> towards becoming compliant with the GDPR (the European Union's General
> >> Data Protection Regulation). In this first step we are trying to make
> >> publicly-visible websites and services GDPR compliant.
> >>
> >> All websites run by the ASF must be compliant with the new website
> >> privacy policy and add a link to it:
> >> https://privacy.apache.org/policies/privacy-policy-public.html
> >>
> >> Please remove all “custom” privacy policies.
> >>
> >> For further changes we have established a FAQ:
> >> https://privacy.apache.org/faq/committers.html
> >>
> >> One of the biggest impacts might be the removal of Google Analytics.
> >> Personally, I believe we should not track our visitors at all.
> >> However, I understand the need to improve our websites. For that
> >> reason volunteers have created a VM and installed Matomo as a Google
> >> Analytics replacement.
> >>
> >> You can look at Matomo here:
> >> https://analytics.apache.org/
> >>
> >> If you need to learn more about your users, you can ask for a site ID
> >> and tracking code at priv...@apache.org and join Apache Flink, Apache
> >> Shiro, Apache Maven and others.
> >>
> >> Please note that we are still learning about the new system and will
> >> add projects one by one.
> >>
> >> We hope that all projects can link to the new privacy policy and
> >> remove Google Analytics until 22nd of July 2022.
> >>
> >> If you have any doubts or questions, or need help, please don’t
> >> hesitate to ask. Also, if you have improvements or suggestions for the
> >> public privacy policy - let us know.
> >>
> >> You can reach out to priv...@apache.org (mailing list) or by replying
> >> to me directly.
> >>
> >> Kind regards,
> >> Christian Grobmeier
> >>
> >> --
> >> The Apache Software Foundation
> >> V.P., Data Privacy
>

Re: [DISCUSS] New data privacy policy & analytics in CLI

[Jesse]

Yeah, I’ll look at that next. 


> On Apr 30, 2022, at 5:37 AM, Niklas Merz  wrote:
> 
> That's great. Thanks Jesse for taking care of this.
> 
> What do you think about our CLI telemetrics? Should we change something
> there?
> 
>> On April 28, 2022, Jesse  wrote:
>> Matomo is live, you can see traffic showing up here ...
>> https://analytics.apache.org/index.php?module=CoreHome&action=index&date=2022-
>> 04-27&period=day&idSite=16#?period=day&date=2022-04-
>> 27&idSite=16&category=Dashboard_Dashboard&subcategory=1
>> 
>>> On Sat, Apr 23, 2022 at 9:39 AM Jesse  wrote:
>>> 
>>> 
>>> I’ll have a look at the switch to Matomo, hopefully it’s as easy as
>> GA.
>>> 
>>>> On Apr 23, 2022, at 2:47 AM, Niklas Merz 
>> wrote:
>>>> Hey folks,
>>>> 
>>>> I just had a closer look at the email regarding the new privacy
>> policy
>>>> (attached below). Adding the link is the easy part. Please check
>> out the
>>>> PR https://github.com/apache/cordova-docs/pull/1243
>>>> 
>>>> I am not aware of analytics for the website but we have the
>> telemetry in
>>>> the CLI. Do you think we should change something about this? I
>> don't
>>>> know much about these metrics so looking forward to your
>> suggestions.
>>>> 
>>>> I'm happy to help if changes are needed.
>>>> 
>>>> Regards
>>>> Niklas
>>>> 
>>>> -- Forwarded message -
>>>> From: Christian Grobmeier 
>>>> Date: Thu, Apr 21, 2022 at 1:34 PM
>>>> Subject: New data privacy policy - may impact your websites
>>>> To: priv...@apache.org
>>>> 
>>>>> Dear PMCs,
>>>>> 
>>>>> The Apache Software Foundation takes privacy seriously and works
>>>>> towards becoming compliant with the GDPR (the European Union's
>> General
>>>>> Data Protection Regulation). In this first step we are trying to
>> make
>>>>> publicly-visible websites and services GDPR compliant.
>>>>> 
>>>>> All websites run by the ASF must be compliant with the new
>> website
>>>>> privacy policy and add a link to it:
>>>>> https://privacy.apache.org/policies/privacy-policy-public.html
>>>>> 
>>>>> Please remove all “custom” privacy policies.
>>>>> 
>>>>> For further changes we have established a FAQ:
>>>>> https://privacy.apache.org/faq/committers.html
>>>>> 
>>>>> One of the biggest impacts might be the removal of Google
>> Analytics.
>>>>> Personally, I believe we should not track our visitors at all.
>>>>> However, I understand the need to improve our websites. For that
>>>>> reason volunteers have created a VM and installed Matomo as a
>> Google
>>>>> Analytics replacement.
>>>>> 
>>>>> You can look at Matomo here:
>>>>> https://analytics.apache.org/
>>>>> 
>>>>> If you need to learn more about your users, you can ask for a
>> site ID
>>>>> and tracking code at priv...@apache.org and join Apache Flink,
>> Apache
>>>>> Shiro, Apache Maven and others.
>>>>> 
>>>>> Please note that we are still learning about the new system and
>> will
>>>>> add projects one by one.
>>>>> 
>>>>> We hope that all projects can link to the new privacy policy and
>>>>> remove Google Analytics until 22nd of July 2022.
>>>>> 
>>>>> If you have any doubts or questions, or need help, please don’t
>>>>> hesitate to ask. Also, if you have improvements or suggestions
>> for the
>>>>> public privacy policy - let us know.
>>>>> 
>>>>> You can reach out to priv...@apache.org (mailing list) or by
>> replying
>>>>> to me directly.
>>>>> 
>>>>> Kind regards,
>>>>> Christian Grobmeier
>>>>> 
>>>>> --
>>>>> The Apache Software Foundation
>>>>> V.P., Data Privacy
>>> 

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

June board report

[Jesse]

It's that time again.

I have sent a pr for the board report here:
https://github.com/apache/cordova-apache-board-reports/pull/16

Please review and reply if you want to add or change anything.

The deadline to submit is Wednesday.

Cheers,
  Jesse

Re: Interest in contributing to cordova-paramedic project

[Jesse]

Hi Hudson,

I am forwarding this to your email address in case you are not subscribed to 
the cordova dev list. 
Please see Julio’s answer below. 

Cheers,
  Jesse

> On Jul 30, 2022, at 5:01 AM, julio cesar sanchez  
> wrote:
> 
> Hi,
> 
> The Apache projects are public and require no permissions to contribute,
> you fork the project and send a pull request fixing the issue and the team
> will evaluate and merge if they consider it a good contribution.
> 
> Then , if you keep contributing over time and your contributions are
> considered valuable a member can propose you to be a maintainer with write
> permissions so you don’t need to wait for reviews to merge (but still a
> good practice to wait for input/approval despite you don’t need to)
> 
>> El El sáb, 30 jul 2022 a las 10:32,  escribió:
>> 
>> Hi there,
>> 
>> My name is Hudson and I am a QA Automation Engineer. I am working
>> especially with mobile frameworks, including Cordova. I am currently using
>> cordova-paramedic for a set of Cordova plugin tests. I have run into a
>> couple of issues with cordova-paramedic along the way and I would be
>> willing to help contribute to this project if possible to help resolve
>> these and other issues. How does the process work for being added as a
>> contributor and gaining access to create PRs for open issues?
>> 
>> Thanks,
>> Hudson
>> -
>> 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

Sept Board Report

[Jesse]

It's that time again.

Draft report is here:
https://github.com/apache/cordova-apache-board-reports/blob/master/2022/09.md

Please review and reply if you want to add or change anything.

The deadline to submit is Wednesday.

Cheers,
  Jesse

Re: Plugin Search

[Jesse]

#2 makes the most sense to me too, easiest to support long term

> On Oct 21, 2022, at 8:17 AM, julio cesar sanchez  
> wrote:
> 
> +1 to option #2
> 
> Niklas, option 2 already mentions having a link to the npm search with
> cordova ecosystem prefilled for easier searching of other 3rd party plugins
> 
>> El El vie, 21 oct 2022 a las 16:39, Niklas Merz 
>> escribió:
>> 
>> I'm +1 on #2, too. Making clear which plugins are Official and supported
>> actively is a good idea. And just a simple note on how to find more on
>> npm is enough IMHO.
>> 
>>> On October 21, 2022, Norman Breau  wrote:
>>> Hi Team,
>>> 
>>> I want to reach a final verdict on how deal with the broken search
>>> page
>>> at https://cordova.apache.org/plugins/
>>> 
>>> We have an active issue being tracked at
>>> https://github.com/apache/cordova-docs/issues/1128 but in summary,
>>> the rest service used to power the search has gone offline and
>>> doesn't
>>> appear to be coming back.
>>> 
>>> Throughout the thread there has been several ideals about how to move
>>> forward including:
>>> 
>>> 1. Using another third-party API service: https://api-docs.npms.io/
>>> 2. Having a static page listing the officially supported Apache
>>> plugins,
>>> with a link to https://www.npmjs.com/search?q=ecosystem%3Acordova
>>> 3. Removing the page entirely, maybe with a blog post explaining how
>>> to
>>> find third-party plugins.
>>> 
>>> Additionally there are few ideas floated around with using the NPM
>>> Couch
>>> API directly, but there may be terms of use issues involved without
>>> having self-managed server hosting a mirror.
>>> 
>>> Personally, I vote -1 for #1 and #3. npms.io doesn't have a clear
>>> terms
>>> of use, as far as I can find. I'm not sure if the API matches the old
>>> npmsearch that we did use, and we may just run into the same issue
>>> down the road. For #3, community members have already explicitly
>>> expressed dissent with removing the page entirely.
>>> 
>>> I vote +1 for #2, having the static page with a mention + link to NPM
>>> for third-party plugins. I think this is most likely the best path
>>> forward.
>>> 
>>> 
>>> 
>>> -
>>> 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: statusbar styles decision

[Jesse]

#1
The intent of default was always to do the platform / system default thing. 

Default on Android need not look like default on iOS 

> On Oct 25, 2022, at 8:01 AM, julio cesar sanchez  
> wrote:
> 
> The funny thing is default is not the default value, the default value is
> lightContent. It’s called default just to match the iOS name. So another
> reason to deprecate it.
> 
>> El El mar, 25 oct 2022 a las 16:37, Norman Breau 
>> escribió:
>> 
>> I think if we (Apache) used the term "default", it should be referencing
>> our default, and not necessarily the underlying platform's default.
>> 
>> Therefore, I think #2 might be the best path moving forward. Adding
>> a styleDarkContent will be symmetrical to the styleLightContent counterpart
>> (we have light & dark opposites). And if the user wants to match the system
>> theme, having styleSystem is think is a clear indication of that
>> behaviour, more
>> so than a styleDefault.
>> 
>> So +1 for Option #2.
>> 
>>> On 2022-10-25 6:08 a.m., julio cesar sanchez wrote:
>>> The statusbar plugin has this styles:
>>> 
>>>- *StatusBar.styleDefault*: Use the default statusbar (dark text, for
>>>light backgrounds)
>>>- *StatusBar.styleLightContent:* Use the lightContent statusbar
>> (light
>>>text, for dark backgrounds).
>>> 
>>> This was enough until iOS 13 came out, then Apple added DarkContent to be
>>> the dark text and changed default to change according to the user theme.
>>> 
>>> Since *StatusBar.**styleDefault* was setting the text to whie in some
>> cases
>>> now, I changed it to work as the docs say, always use dark text (asked on
>>> the issue and users wanted it like that). But after it was merged, some
>>> users started to say that we should provide a new
>>> *StatusBar.styleDarkContent* and make *StatusBar.**styleDefault *work as
>>> the native default value (change according to the configured user theme).
>>> 
>>> So, what should we do?
>>> 
>>> 1) Add a new *StatusBar.styleDarkContent *method that would work as the
>>> *StatusBar.**styleDefault* works now, dark text, and change *StatusBar.*
>>> *styleDefault* to use the native default value so it changes according to
>>> the user theme.
>>> 
>>> 2) Add a new *StatusBar.styleDarkContent *method that would work as the
>>> styleDefault works now, dark text, add another new
>> *StatusBar.styleSystem*
>>> (or similar name)  to use the native default value so it changes
>> according
>>> to the user theme, and deprecate *StatusBar.**styleDefault*.
>>> 
>>> 3) Keep the *StatusBar.**styleDefault* for dark text and add a new
>>> *StatusBar.styleSystem* (or similar name) to make the status bar change
>>> according to the user theme.
>>> 
>>> Next release is going to be a major release, so we shouldn't worry about
>>> breaking changes. But not sure which change would be the least confusing
>>> for users, matching the style names to the native iOS names and their
>>> bebavior, keep default as dark text as that's what is documented or use a
>>> more neutral name for style changing according to the theme.
>>> 
>>> Note, it's not clear if we can accomplish the status bar style change
>>> according to the user/phone theme on Android.
>>> 
>> 
>> -
>> 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] Enable github discussions

[Jesse]

Hello all,

github discussions are a great way of keeping code conversations very close
to the actual code and I think would suit our project better than our use
of #slack

The apache airflow project switched to use discussions [1]
This is not configurable via asf.yml [2] and requires an infra ticket
linking a consensus reaching discussion. [3]

I propose that we enable discussions on the apache/cordova repo [4] to
evaluate, and we can possibly make a decision to include other repos later.

What do you think?

Cheers,
  Jesse

[1]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632#GitHubIssues/Discussions-GithubIssuesandDiscussions
[2]
https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features
[3]
https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-GitHubDiscussions
[4] https://github.com/apache/cordova

Re: [DISCUSS] Enable github discussions

[Jesse]

... and it's live!
https://github.com/apache/cordova/discussions

On Mon, Nov 21, 2022 at 8:45 AM gandhi rajan 
wrote:

> + 1
>
> Github discussions help in easy and transparent interactions.
>
> On Sun, 20 Nov 2022 at 14:26, Jesse  wrote:
>
> > Hello all,
> >
> > github discussions are a great way of keeping code conversations very
> close
> > to the actual code and I think would suit our project better than our use
> > of #slack
> >
> > The apache airflow project switched to use discussions [1]
> > This is not configurable via asf.yml [2] and requires an infra ticket
> > linking a consensus reaching discussion. [3]
> >
> > I propose that we enable discussions on the apache/cordova repo [4] to
> > evaluate, and we can possibly make a decision to include other repos
> later.
> >
> > What do you think?
> >
> > Cheers,
> >   Jesse
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632#GitHubIssues/Discussions-GithubIssuesandDiscussions
> > [2]
> >
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features
> > [3]
> >
> >
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-GitHubDiscussions
> > [4] https://github.com/apache/cordova
> >
>
>
> --
> Regards,
> Gandhi
>
> "The best way to find urself is to lose urself in the service of others
> !!!"
>

December board report ( review )

[Jesse]

Please have a quick look at the board report here:
https://github.com/apache/cordova-apache-board-reports/pull/18

I missed the reminder on this one so it is actually overdue already so I
will be submitting it soon.  I have answered the pending question on our
slack use, as well as processing recent resignations of Dmitry, Ray, Murat.

Let me know if there is anything you would like to add/change either here
or as a comment on the pr.

Cheers,
  Jesse

March board report

[Jesse]

I have posted the draft of this quarter's report.
https://github.com/apache/cordova-apache-board-reports/blob/master/2023/03.md

Let me know if there is anything you would like to add/change either here
or as a comment or pr.

Cheers,
  Jesse

Re: March board report

[Jesse]

Yeah, good points.

For the question of sending it to the list, I think the answer of, 'We are
using github discussions now ...' should be sufficient.
On the second point, this to me is just anecdotal, and I don't think it
requires a response, but if you would like to add something we can.

Cheers,
  Jesse


On Wed, Mar 15, 2023 at 12:01 AM Niklas Merz  wrote:

> Thanks Jesse!
>
> The board had feedback we might want to address last time:
>
> >cd: Thank you very much for replying to my question and for at least
>  >addressing the issues ... would it be possible to send that
>  >digest to the dev-list? I doubt any person familiar would know
>  >where to look.
>
> This is about the slack digest. As we are using GitHub discussions more
> and more it's not that important and we could think about closing Slack?
> Let's start a discussion about that.
>
>  >rbowen: At the recent DroidCon Android developers conference in
>  >Kenya, I was unable to find any developers who were aware of
>  >Cordova. I encourage you to submit some talks to regional
>  >mobile developer events to increase awareness of your
>  >platform.
>
> Do we have anything to say about that. I will be speaking at a local
> meetup in June but the talk is mostly about contributing to OSS in
> general. Cordova will be mentioned as an example why it's important to
> give back.
>
> Kind regards
> Niklas
>
> On March 15, 2023, Jesse  wrote:
> > I have posted the draft of this quarter's report.
> > https://github.com/apache/cordova-apache-board-
> > reports/blob/master/2023/03.md
> >
> > Let me know if there is anything you would like to add/change either
> > here
> > or as a comment or pr.
> >
> > Cheers,
> >  Jesse
>

June board report

[Jesse]

I've put together a draft of this quarter's report.
Feel free to comment, correct, add, review ...
https://github.com/apache/cordova-apache-board-reports/pull/19

Cheers,
  Jesse

Re: SplashScreen

[Jesse]

Hello,
This mailing list is for discussions regarding the development of Apache
Cordova and not for support.

For support and/or questions about how to use Apache Cordova, please use
GitHub Discussions at
https://github.com/apache/cordova/discussions

Thank you,

On Thu, Jun 15, 2023 at 4:36 AM Leonel Gregio Auler 
wrote:

> Hello everyone !
>
> I have a doubt, I'm upgrading to Cordova 12, is the first time that I'm
> using splashscreen without plugin. Before, my application used the 10
> version.
>
> I don't know how is the code that I have to do in config.xml and
> splashscreen.xml
>
> Anyone can help me, please ?
>
> Att,
>
>
>
>
>
>
> LEONEL GREGIO AULER
> TECH LEAD
>
>
>
> (51) 98102-1381
> *leonel.au...@mouts.info *
>
> --
> *De:* Leonel Gregio Auler 
> *Enviado:* quinta-feira, 15 de junho de 2023 01:18
> *Para:* dev@cordova.apache.org 
> *Assunto:* SplashScreen
>
> Hello everyone !
>
> I have a doubt, I'm upgrading to Cordova 12, is the first time that I'm
> using splashscreen without plugin. Before, my application used the 10
> version.
>
> I don't know how is the code that I have to do in config.xml and
> splashscreen.xml
>
> Anyone can help me, please ?
>
> Att,
>
>
>
>
>
> LEONEL GREGIO AULER
> TECH LEAD
>
>
>
> (51) 98102-1381
> *leonel.au...@mouts.info *
>
>

[DISCUSS] Create new mailing list for logging github discussions

[Jesse]

I have made the change to github.com/apache/cordova so that all discussion
activity will be sent to our (dev) mailing list.  There has been some
concern raised in slack#pmc that this will flood the dev list which we use
specifically for cordova development, and NOT for support.
For years now, when anyone has sent a message to the dev list asking a 'how
to use cordova' question, we have flatly told them:
|  "This mailing list is for discussions regarding the development of
Apache Cordova and not for support.  For support and/or questions about how
to use Apache Cordova, please use GitHub Discussions ... "
So it does seem a little weird if those discussions end up right back here.

A vote will follow shortly (tomorrow) proposing that we create a new
mailing list disc...@cordova.apache.org and route all github discussion
activity there.

Please use this thread to weigh alternatives, of which I see a few:
- do nothing, set up your own filters if you are annoyed by the extra email
on dev
- route this traffic to issues, which is already collecting all gh issues,
pull requests and comments
- create a new list, but with some other name to avoid confusion with
[DISCUSS] threads

Cheers,
  Jesse

Re: [DISCUSS] Create new mailing list for logging github discussions

[Jesse]

Since I have not heard anything here, I am assuming that the way things are
is fine.

Cheers,
  Jesse

On Wed, Jun 28, 2023 at 11:31 PM Jesse  wrote:

> I have made the change to github.com/apache/cordova so that all
> discussion activity will be sent to our (dev) mailing list.  There has been
> some concern raised in slack#pmc that this will flood the dev list which we
> use specifically for cordova development, and NOT for support.
> For years now, when anyone has sent a message to the dev list asking a
> 'how to use cordova' question, we have flatly told them:
> |  "This mailing list is for discussions regarding the development of
> Apache Cordova and not for support.  For support and/or questions about how
> to use Apache Cordova, please use GitHub Discussions ... "
> So it does seem a little weird if those discussions end up right back here.
>
> A vote will follow shortly (tomorrow) proposing that we create a new
> mailing list disc...@cordova.apache.org and route all github discussion
> activity there.
>
> Please use this thread to weigh alternatives, of which I see a few:
> - do nothing, set up your own filters if you are annoyed by the extra
> email on dev
> - route this traffic to issues, which is already collecting all gh issues,
> pull requests and comments
> - create a new list, but with some other name to avoid confusion with
> [DISCUSS] threads
>
> Cheers,
>   Jesse
>

[VOTE} mailing list for logging github discussions

[Jesse]

Please review and vote by replying to this email, and keeping discussion on
the [DISCUSS] thread. ( note: subject is changed )
> [DISCUSS] Create new mailing list for logging github discussions

This vote is to direct all github discussion generated email to
iss...@cordova.apache.org, instead of the current setting which sends it
all to the dev list.

Upon a successful vote I will update infra settings to direct all github
discussion activity to iss...@cordova.apache.org.

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

Re: [VOTE} mailing list for logging github discussions

[Jesse]

The vote has now closed. The results are:

Positive Binding Votes: 4

Jesse MacFadyen
Darryl Pogue
Norman Breau
Niklas Merz

Negative Binding Votes: 0
Other Votes: 0

The vote has passed.

On Sun, Jul 9, 2023 at 8:07 AM Niklas Merz  wrote:

> I vote +1
>
> On July 9, 2023, Norman Breau  wrote:
> > I vote +1
> >
> > On 2023-07-08 1:00 a.m., Darryl Pogue wrote:
> > > I vote +1
> > >
> > > On Fri, Jul 7, 2023 at 8:38 PM Jesse 
> > wrote:
> > >
> > >> Please review and vote by replying to this email, and keeping
> > discussion on
> > >> the [DISCUSS] thread. ( note: subject is changed )
> > >>> [DISCUSS] Create new mailing list for logging github discussions
> > >> This vote is to direct all github discussion generated email to
> > >> iss...@cordova.apache.org, instead of the current setting which
> > sends it
> > >> all to the dev list.
> > >>
> > >> Upon a successful vote I will update infra settings to direct all
> > github
> > >> discussion activity to iss...@cordova.apache.org.
> > >>
> > >> 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
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
>

Apple privacy manifest

[Jesse]

Has anyone looked at privacy manifests for iOS apps?
…
> > As you may know, in June, Apple announced new features to help users 
> > understand developers’ privacy and data collection and sharing practices. 
> > These new features include privacy manifests and signatures, which we 
> > encourage all third-party SDKs to adopt to provide transparency to users 
> > and help secure the software supply chain. Third-party SDKs that impact 
> > user privacy will be expected to include a privacy manifest and signature, 
> > and starting in Spring 2024, new and updated apps that include these 
> > third-party SDKs will need to include their manifest and signature to 
> > submit to the App Store

Re: Apple privacy manifest

[Jesse]

gt;> SDK providers to embed their xcprivacy plist as part of a framework
>>> bundle.
>>>> Apps that use the framework will inherit the privacy declarations of
>>> their
>>>> SDK frameworks in addition to their own declarations.
>>>>  Separately, but at the same time, Apple is introducing code signing
>>> to
>>>> framework bundles to help app developers better trust that their
>>> frameworks
>>>> came from trusted/consistent sources.
>>>>What does this mean for Cordova?
>>>> 
>>>>  If we take the simplest interpretation: nothing. Cordova is not
>>> distributed
>>>> as a framework or SDK bundle, it is source code that's included in
>>> the app
>>>> (both CordovaLib and any installed plugins). Therefore, Cordova
>>> itself
>>>> technically doesn't need to provide any privacy plists and it's up
>>> to the
>>>> app developer to handle all the declarations based on how they're
>>> using
>>>> Cordova.
>>>>  However, that kinda sucks for app developers, who might not know if
>>> a
>>>> particular plugin uses privacy-impacting APIs (such as
>>> NSUserDefaults, or
>>>> file system access). The problem for us is that because plugins are
>>> not
>>>> distributed as framework bundles, we cannot provide xcprivacy plist
>>> files
>>>> for each plugin and rely on Apple automatically merging them.
>>>>Suggestions for now
>>>> ---
>>>>  1. Add a blank PrivacyInfo.xcprivacy plist file to the Cordova iOS
>>> template
>>>> as a resource.
>>>>  2. Add a (mostly blank, but accurate) PrivacyInfo.xcprivacy plist
>>> file to
>>>> CordovaLib as a resource, so that it's available for anyone
>>> consuming
>>>> CordovaLib from Swift Package Manager or as a framework (unclear to
>>> me how
>>>> this impacts Cocoapods...)
>>>>  3. I guess our best option right now is to have plugins that need to
>>> make
>>>> declarations do so via  into the xcprivacy plist, which
>>> is
>>>> going to be super prone to conflicts if multiple plugins need to add
>>> the
>>>> same declarations :(
>>>>I really don't like the idea of relying on edit-config/config-file
>>>> injection behaviour to manage this plist, because it's almost
>>> guaranteed to
>>>> cause conflict issues when adding/removing plugins, but I don't have
>>> better
>>>> ideas at the moment. It doesn't seem feasible to change things such
>>> that
>>>> each plugin ends up as a framework bundle, since that would be a
>>> major
>>>> architectural change (although perhaps one that needs to happen?)
>>>>If we have specific questions for Apple where we need clarification
>>> or
>>>> recommendations, I can reach out to someone there and see if we can
>>> get any
>>>> help.
>>>>  ~Darryl
>>>>  On Fri, Oct 27, 2023 at 8:28 AM Jesse 
>>> wrote:
>>>>  
>>>>> Has anyone looked at privacy manifests for iOS apps?
>>>>> …
>>>>>>> As you may know, in June, Apple announced new features to help
>>> users
>>>>> understand developers’ privacy and data collection and sharing
>>> practices.
>>>>> These new features include privacy manifests and signatures, which
>>> we
>>>>> encourage all third-party SDKs to adopt to provide transparency to
>>> users
>>>>> and help secure the software supply chain. Third-party SDKs that
>>> impact
>>>>> user privacy will be expected to include a privacy manifest and
>>> signature,
>>>>> and starting in Spring 2024, new and updated apps that include
>>> these
>>>>> third-party SDKs will need to include their manifest and signature
>>> to
>>>>> submit to the App Store
>>>>>
>>> 
>>> -
>>> 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

Nomination for a new chair for Apache Cordova

[Jesse]

Hello friends! I have been the chair of Apache Cordova since around
December of 2018, roughly 5 years. My duties of late have been mostly
administrative: board reports, PMC management etc. Some of it is listed
here in the README: https://github.com/apache/cordova-apache-board-reports
I think it is time for new leadership and I have decided to resign my
duties as the Apache Cordova chair. I formally nominate Bryan Ellis as the
next chair.
Bryan has been a consistently motivated contributor to the project and has
been diligently pushing through many of our releases over the last several
years.  I believe Bryan will be great in this new role and I will do my
best to help him. Bryan is very familiar with and helps uphold 'The Apache
Way'
(https://www.apache.org/foundation/how-it-works.html) and he will be a
great liaison with the Board. I won't be far, I plan to remain in the
community and will always be reachable, though I am going to be more
focused on personal goals.   I am always available to answer questions and
help sort issues. Cheers,
  Jesse

Re: Nomination for a new chair for Apache Cordova

[Jesse]

Thank you all.
It appears we have consensus (and PMC member votes).
According to "How to change your PMC's Chair" I have prepared the
resolution below that I will send in 24 hours.
The change should be in effect if the Board approves it, at the next
Board meeting on Dec 20, 2023

-
# Change Cordova Chair

## Resolution to change the chair of a project
WHEREAS, the Board of Directors heretofore appointed Jesse MacFadyen
(purplecabbage) to the office of Vice President, Apache Cordova, and

WHEREAS, the Board of Directors is in receipt of the resignation of
Jesse MacFadyen from the office of Vice President, Apache Cordova, and

WHEREAS, the Project Management Committee of the Apache Cordova project
has chosen by vote to recommend Bryan Ellis (erisu) as the successor to
the post;

NOW, THEREFORE, BE IT RESOLVED, that Jesse MacFadyen is relieved and
discharged from the duties and responsibilities of the office of Vice
President, Apache Cordova, and

BE IT FURTHER RESOLVED, that Bryan Ellis be and hereby is appointed to
the office of Vice President, Apache Cordova, to serve in accordance
with and subject to the direction of the Board of Directors and the
Bylaws of the Foundation until death, resignation, retirement, removal
or disqualification, or until a successor is appointed.

On Tue, Dec 5, 2023 at 5:36 AM Shazron  wrote:

>  +1 !
> Bryan will be great.
> Thank you Jesse for your service!
>
>
> On 2 Dec 2023 at 8:17:57 AM, Tim Brust  wrote:
>
> > +1
> >
> > Bryan has been a great a team member and remains dedicated towards the
> > development since years!
> >
> > On Fri, Dec 1, 2023 at 5:36 PM Norman Breau  wrote:
> >
> > +1
> >
> >
> > On 2023-11-29 9:52 p.m., Jesse wrote:
> >
> > > Hello friends! I have been the chair of Apache Cordova since around
> >
> > > December of 2018, roughly 5 years. My duties of late have been mostly
> >
> > > administrative: board reports, PMC management etc. Some of it is listed
> >
> > > here in the README:
> >
> > https://github.com/apache/cordova-apache-board-reports
> >
> > > I think it is time for new leadership and I have decided to resign my
> >
> > > duties as the Apache Cordova chair. I formally nominate Bryan Ellis as
> >
> > the
> >
> > > next chair.
> >
> > > Bryan has been a consistently motivated contributor to the project and
> >
> > has
> >
> > > been diligently pushing through many of our releases over the last
> >
> > several
> >
> > > years.  I believe Bryan will be great in this new role and I will do my
> >
> > > best to help him. Bryan is very familiar with and helps uphold 'The
> >
> > Apache
> >
> > > Way'
> >
> > > (https://www.apache.org/foundation/how-it-works.html) and he will be a
> >
> > > great liaison with the Board. I won't be far, I plan to remain in the
> >
> > > community and will always be reachable, though I am going to be more
> >
> > > focused on personal goals.   I am always available to answer questions
> >
> > and
> >
> > > help sort issues. Cheers,
> >
> > >Jesse
> >
> > >
> >
> >
> > -
> >
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
> >
> >
>

December board report

[Jesse]

Somehow I missed this, usually I get notified ahead of time.  The board
report was supposed to be filed 1 week prior to tomorrow's meeting.

https://github.com/apache/cordova-apache-board-reports/blob/master/2023/12.md

I'll send it now since its late, if anyone has any changes we can amend it,
or mention it in the next report.

Cheers,
  Jesse

Re: [VOTE] Cordova-Electron 4.0.0 Release

[Jesse]

+1

- code review
- built a new electron app

On Sat, Mar 9, 2024 at 3:00 AM Niklas Merz  wrote:

> I vote +1
>
> * signature ok
> * hash ok
> * new app builds with this platform on my system
> * tag ok
> * tests pass locally
> * changes look good
> * licenses & headers look ok
>
> On March 5, 2024, Erisu  wrote:
> > Please review and vote on this Electron Release v4.0.0
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The archive has been published to dist/dev:
> >  https://dist.apache.org/repos/dist/dev/cordova/electron-v4.0.0
> >
> >
> > The package was published from its corresponding git tag:
> >  cordova-electron: 4.0.0 (d2192b20dc)
> >
> >
> > Note that you can test it out via:
> >  cordova platform add https://github.com/apache/cordova-electron#4.0.0
> >
> >
> > 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 the `npm audit` report was sufficient for release
> > * Ensured continuous build was green when repo was tagged
> > * Ran `npm test`
> > * Ran following `cordova` test in sample project:
> >  * `cordova platform add cordova-electron-4.0.0.tgz`
> >  * `cordova plugin add`
> >  * `cordova build electron`
> >  * `cordova run electron —nobuild`
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
>

Re: [VOTE] Plugins Release

[Jesse]

+1

@purplecabbage
risingj.com

On Tue, Apr 21, 2015 at 10:29 AM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> I vote +1
>
> * Performed manual ad-hoc testing
>
> -Sergey Grebnov
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Tuesday, April 21, 2015 10:16 AM
> To: dev@cordova.apache.org
> Subject: Re: [VOTE] Plugins Release
>
> Need 1 more vote
>
> On Thu, Apr 16, 2015 at 9:50 AM, Parashuram N (MS OPEN TECH) <
> panar...@microsoft.com> wrote:
>
> > +1 vote
> >
> >
> > * Verified signatures and hashes
> > * Verified tags
> > * Verified plugins added correctly to blank
> > * Verified blank app can be successfully ran and built for
> > * Ran smoke testing of mobilespec app
> > * Performed manual ad-hoc testing
> > * Verified Release Notes
> >
> > -Original Message-
> > From: Steven Gill [mailto:stevengil...@gmail.com]
> > Sent: Wednesday, April 15, 2015 4:25 PM
> > To: dev@cordova.apache.org
> > Subject: [VOTE] Plugins Release
> >
> > 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-8858
> >
> > The plugins have been published to
> > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8858/
> >
> > The packages were published from their corresponding git tags:
> > cordova-plugin-battery-status: 1.0.0 (21ac0286c1)
> > cordova-plugin-camera: 1.0.0 (d10bf50c61)
> > cordova-plugin-console: 1.0.0 (293a261bac)
> > cordova-plugin-contacts: 1.0.0 (e95ba2e805)
> > cordova-plugin-device: 1.0.0 (a159702f79)
> > cordova-plugin-device-motion: 1.0.0 (7a7b94e9a9)
> > cordova-plugin-device-orientation: 1.0.0 (ec0f27f4ae)
> > cordova-plugin-dialogs: 1.0.0 (6b06471ccc)
> > cordova-plugin-file: 2.0.0 (9133873282)
> > cordova-plugin-file-transfer: 1.0.0 (490063e1e5)
> > cordova-plugin-geolocation: 1.0.0 (6dcc55b2a9)
> > cordova-plugin-globalization: 1.0.0 (cc9c7c2113)
> > cordova-plugin-inappbrowser: 1.0.0 (7d1b584306)
> > cordova-plugin-media: 1.0.0 (12271f8633)
> > cordova-plugin-media-capture: 1.0.0 (cd3a586252)
> > cordova-plugin-network-information: 1.0.0 (30d51f8f32)
> > cordova-plugin-splashscreen: 2.0.0 (d23ea4e011)
> > cordova-plugin-statusbar: 1.0.0 (261f9576fe)
> > cordova-plugin-test-framework: 1.0.0 (a2b4871a02)
> > cordova-plugin-vibration: 1.0.0 (894310ecfb)
> >
> > 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
> >
> > 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 mobile spec on Android and iOS
> >
> > -
> > 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: Proposal: Expose check_reqs at the CLI level

[Jesse]

I liked 'doctor', I don't think it is cute, it is in use elsewhere.
The words always seem to be the hard part, here are some alternatives :

doctor
requirements
examine
exam
diagnose
check
audit
inspect
eval



@purplecabbage
risingj.com

On Wed, Apr 22, 2015 at 9:43 AM, Josh Soref  wrote:

> We're going to type it often enough that I'd be upset at both check_reqs
> and check-requirements
>
> "requirements" is good enough.
>
> > -Original Message-
> > From: Treggiari, Leo [mailto:leo.treggi...@intel.com]
> > Sent: Wednesday, April 22, 2015 11:11 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: Expose check_reqs at the CLI level
> >
> > Hi Vladimir,
> >
> > It's great to see this being worked on and discussed.  My comments below
> > are mine and mine alone.
> >
> > In addition to the code changes, I would have preferred to see a
> specification
> > of the command, e.g.
> >
> >   cordova check-reqs platform [platform...]
> >
> > I took a quick look at the CLI code changes and didn't see any option
> > processing.  Are there any options?
> > Do the platform(s) specified on the command need to have been already
> > added to the project?
> > Does the command require a project - i.e. be executed in a project
> directory?
> > Regarding the command name, I don't think being 'cute' is helpful to
> users -
> > i.e. I recommend against 'doctor'.
> > I think 'check-requirements' would be OK.  It's long but how many times
> does
> > a user need to type it?
> >
> > Thanks,
> > Leo
> >
> > -Original Message-
> > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com]
> > Sent: Wednesday, April 22, 2015 7:18 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: Expose check_reqs at the CLI level
> >
> > Hey, guys. Have anyone looked at it?
> > I've made some refactoring to make changes more readable, and updated
> > data contract between platform's check_reqs code and LIB API.
> >
> > Josh, regarding command name. I thought that there is still no agreement
> > about verb name.
> > Personally I agree that `cordova doctor` or `cordova requirements` sounds
> > better, but this is just a command name ant it could be changed at any
> time.
> >
> > ---
> > Best regards, Vladimir
> >
> > -Original Message-
> > From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
> > Sent: Monday, 20 April, 2015 22:04
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: Expose check_reqs at the CLI level
> >
> > This was only an initial implementation - no pull request has been sent.
> I
> > think this is just a way for folks to play with what Vlad has now. I am
> sure we
> > will change the verb name before a PR comes in.
> >
> > -Original Message-
> > From: Josh Soref [mailto:jso...@blackberry.com]
> > Sent: Monday, April 20, 2015 11:59 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: Expose check_reqs at the CLI level
> >
> > -1
> >
> > Didn't everyone agree to call it `cordova doctor` or worst, `cordova
> > requirements`?
> >
> > > -Original Message-
> > > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com]
> > > Sent: Monday, April 20, 2015 11:46 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: Proposal: Expose check_reqs at the CLI level
> > >
> > > Hi, list.
> > >
> > > I would like to share a draft implementation for check_reqs command
> > > and check_reqs API:
> > > Changes  could be found here:
> > > CLI: https://github.com/apache/cordova-
> > > cli/compare/master...MSOpenTech:requirements_check
> > > LIB: https://github.com/apache/cordova-
> > > lib/compare/master...MSOpenTech:requirements_check
> > > Cordova-android: https://github.com/apache/cordova-
> > > android/compare/master...MSOpenTech:requirements_check
> > >
> > > The implementation consists of following:
> > > 1. 'cordova check-reqs' command for cordova CLI, which calls
> > > corresponding cordova-lib API with options, specified from CLI
> > >
> > > 2. 'check_reqs' module for cordova-lib, which works as a wrapper
> > > around platforms' check_reqs scripts. It returns a promise, either
> > > resolved if check_reqs platform script is found and ran successfully
> > > or rejected in case if check_reqs script is failed due to some
> internal errors
> > or not found at all.
> > >
> > > 3. check_reqs script for android platform, updated to return array of
> > > requirements.
> > >
> > > * Each requirements is an object with following fields:
> > > - id - some short id, could be useful for tools, that consume
> API directly
> > > - name - readable name for this requirement, such as 'Jav JDK'
> > > or 'Gradle build tools', etc.
> > > - installed - Boolean paremeter that indicates if requirement
> > > is properly installed/satisfied
> > > - reason - error, reported by requirements check routines if
> > > requirement is missing.
> > >
> > > Please note that work is still in progress, and will be changed
> > 

Re: Buildbot: buildslave cordova-ios-slave was lost

[Jesse]

Thanks Dmitry!

oh no! It happened again!

@purplecabbage
risingj.com

On Thu, Apr 23, 2015 at 3:10 PM, Dmitry Blotsky 
wrote:

> OSX slave went down because it lost contact with the master for some
> reason. Back up now.
>
> -Original Message-
> From: build...@apache.org [mailto:build...@apache.org]
> Sent: Thursday, April 23, 2015 2:37 PM
> To: dev@cordova.apache.org
> Subject: Buildbot: buildslave cordova-ios-slave was lost
>
> The Buildbot working for 'ASF Buildbot'
> has noticed that the buildslave named cordova-ios-slave went away
>
> It last disconnected at Thu Apr 23 21:31:41 2015 (buildmaster-local time)
>
> The admin on record (as reported by BUILDSLAVE:info/admin) was 'Your Name
> Here  '.
>
> Sincerely,
>  The Buildbot
>  http://ci.apache.org/
>
> http://ci.apache.org/buildslaves/cordova-ios-slave
>
> -
> 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: Buildbot: buildslave cordova-ios-slave was lost

[Jesse]

No worries, glad you're on it!

@purplecabbage
risingj.com

On Thu, Apr 23, 2015 at 3:49 PM, Dmitry Blotsky 
wrote:

> Yep. Turns out it was falling asleep. I recently wiped the machine and
> forgot to uncheck the "Fall asleep sometimes" option. That was silly. Sorry
> about that.
>
> -Original Message-
> From: Jesse [mailto:purplecabb...@gmail.com]
> Sent: Thursday, April 23, 2015 3:43 PM
> To: dev@cordova.apache.org
> Subject: Re: Buildbot: buildslave cordova-ios-slave was lost
>
> Thanks Dmitry!
>
> oh no! It happened again!
>
> @purplecabbage
> risingj.com
>
> On Thu, Apr 23, 2015 at 3:10 PM, Dmitry Blotsky 
> wrote:
>
> > OSX slave went down because it lost contact with the master for some
> > reason. Back up now.
> >
> > -Original Message-
> > From: build...@apache.org [mailto:build...@apache.org]
> > Sent: Thursday, April 23, 2015 2:37 PM
> > To: dev@cordova.apache.org
> > Subject: Buildbot: buildslave cordova-ios-slave was lost
> >
> > The Buildbot working for 'ASF Buildbot'
> > has noticed that the buildslave named cordova-ios-slave went away
> >
> > It last disconnected at Thu Apr 23 21:31:41 2015 (buildmaster-local
> > time)
> >
> > The admin on record (as reported by BUILDSLAVE:info/admin) was 'Your
> > Name Here  '.
> >
> > Sincerely,
> >  The Buildbot
> >  http://ci.apache.org/
> >
> > http://ci.apache.org/buildslaves/cordova-ios-slave
> >
> > -
> > 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: [Android] InAppBrowser and URI whitelisting

[Jesse]

What does the browser do? That's what the InAppBrowser should do ...

It may also make sense to allow the host cordova app decide whether or not
to allow it.
Presumably the host app could allow all intents, but not want to extend
that to it's InAppBrowser control, or allow some intents for some domains
... based on their own logic ...
Ideally, I think this should be a user problem, ie. give the app developer
a chance to intercept the request, and if they don't just perform the
default browser behaviour.





@purplecabbage
risingj.com

On Fri, Apr 24, 2015 at 2:34 PM, Joe Bowser  wrote:

> Hey
>
> I was looking at CB-8180, and I'm wondering what the correct behaviour for
> intents being launched from URIs should be for an InAppBrowser.  Should
> these have free reign to open whatever, or should they also be bound by the
> rules of the whitelist?
>
> What do people think?
>
> Joe
>

//build conference

[Jesse]

Hi all,

Shaz and I will be attending the microsoft //build event this week, and I
thought I would shout out here to see who else is attending? It would be
great to meet face to face.
Also, we're hosting a meetup[1] in our office tomorrow night, if anyone
didn't get the word via other social channels. Come by if you can.

[1] http://www.meetup.com/PhoneGap-SF/events/221551303/


@purplecabbage
risingj.com

Re: Apache Cordova 4 Programming book

[Jesse]

Congrats John!

@purplecabbage
risingj.com

On Wed, Apr 29, 2015 at 9:09 AM, Kerri Shotts  wrote:

> Congratulations on your book’s release! It’s always nice to finally send
> it out into the world after so many months of hard work. :-)
>
>
>
>
> From: John M. Wargo 
> Reply: dev@cordova.apache.org >
> Date: April 29, 2015 at 6:30:27 AM
> To: dev@cordova.apache.org >
> Subject:  Apache Cordova 4 Programming book
>
> Cordova Devs,
>
> I wanted to let everyone know that Apache Cordova 4 Programming has been
> released and is available online:
> http://www.informit.com/store/apache-cordova-4-programming-9780134048192.
>
> --
> John M. Wargo
> @johnwargo 
> www.johnwargo.com 
>
> --
>

Re: [Proposal - New Feature] Add tag to config.xml to handle images

[Jesse]

What is the use for the images? Is this for a plugin, or an app template?
I can think of a couple ways to do this, but none would affect configure.xml. 
I suggest you look at how the splash screen plugin does this for android. 



> On May 1, 2015, at 8:39 AM, Karen Tran  wrote:
> 
> Hi dev-list,
> 
> I wanted to get your input on a feature I want to add to the config.xml.
> 
> Currently there are only the icon tag and splash tag that allows the user
> to specify the icon and splash image in the config.xml respectively.
> 
> I want to be able to specify multiple images that will be used in my app
> such as customized buttons. The problem is that the icon tag will rename
> the image specified to icon.png, so ultimately the user would only be able
> to change the main icon. And the splash tag of course handles the splash
> image, so I don't want that.
> 
> I propose making a new tag that handles general images. It'll be similar to
> the icon tag, except it won't rename the image. It will copy the image from
> the src, and drop it into the correct drawable-density directory (I am
> working in android).
> 
> I know I can just drop the images myself into the drawable folders, but I
> have to assume that my users won't know the android project structure and
> will only modify the config.xml.
> 
> Any thoughts, comments, or critiques would be appreciated.
> 
> 
> Regards,
> Karen Tran

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

Re: Cordova 5.0.0 "duplicate cordova" check breaks Ripple

[Jesse]

I think ripple will need to change, I'll have a look and see if there is a more 
elegant way to implement honeypot. 



> On Apr 30, 2015, at 7:06 PM, Tim Barham  wrote:
> 
> ​Hey everyone - a bug was filed today against Ripple that it is broken with 
> Cordova 5.0.0. The issue is that Ripple triggers the new "duplicate cordova" 
> check:
> 
> Â Â Â  cordova-js/src/cordova.js line 22: 
> Â Â Â  if ("cordova" in window) { throw new Error("cordova already defined"); 
> };
> 
> Ripple patches cordova by defining a setter for window.cordova to intercept 
> it being created. This is sufficient to make ("cordova" in window) return 
> true.
> I don't see a way to readily resolve this issue in Ripple. We can fix it in 
> Cordova by changing the test to:
> 
>   if (window.cordova) ...
> 
> Couple of questions:
> 1. Any reason not to make this change?
> 2. To get this fix out will require re-releasing all platforms, correct? And 
> I presume a tools release to update the pinned platforms? Is this sufficient 
> reason to trigger such a release?
> 
> Thanks!
> 
> Tim
> ТÐÐ¥FòVç7V'67&–&RÂRÖÖ–âFWb×Vç7V'67&–&T6÷&F÷fæ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖÖ–âFWbÖ†VÇ6÷&F÷fæ6†Ræ÷&pÐ

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

Re: FYI - Moving to new team, seeing me less around here

[Jesse]

Congrats Michal! Good for you!

@purplecabbage
risingj.com

On Mon, May 4, 2015 at 11:49 AM, Steven Gill  wrote:

> It has been great working with you Michal! Learned a lot. Enjoy your new
> project! I'm sure you will kill it.
>
> On Mon, May 4, 2015 at 9:49 AM, Brian LeRoux  wrote:
>
> > Scott is awesome and so is the Physical Web. Huge potential and I'm
> stoked
> > to hear we now have someone on the inside. ;) Congrats Michal!
> >
> > On Mon, May 4, 2015 at 9:38 AM, Shazron  wrote:
> >
> > > Congrats Michal!
> > > Super interesting project.
> > >
> > > On Mon, May 4, 2015 at 7:52 AM, Michal Mocny 
> wrote:
> > > > I've moved to a new team here at Google (Physical Web:
> > > > https://google.github.io/physical-web/).
> > > >
> > > > This means I will likely be speaking up less often going forward,
> > though
> > > > I'll still be keeping an eye on these lists for the foreseeable
> future.
> > > >
> > > > And I'm itching to write some cordova plugins for the Physical Web...
> > > >
> > > > -Michal
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>

Re: Cordova 5.0.0 "duplicate cordova" check breaks Ripple

[Jesse]

Yeah, my reasoning is that it is difficult to update all the affected bits
in cordova.  We can change the cordova logic, but still it will be at least
a week before we can get a new everything out.

Part of my reasoning is that ripple claims to be a '... platform agnostic
mobile application development and testing tool.' We should make that part
true as well.

Personally, I consider ripple's use of 'cordova' to be risky given that we
have certain expectations of how our own library works, which may or may
not be private to cordova.  I would much rather see ripple implement a
ripple-cordova connector class which uses cordova/exec/proxy or some
cordova apis that we purposely publish, which is what I plan to look into
this week. Or we can consider moving to a model where we do define a way to
override the entire cordova object, and document it.


@purplecabbage
risingj.com

On Mon, May 4, 2015 at 3:56 PM, Tim Barham  wrote:

> Hey Jesse - is your reasoning behind that to avoid having to release an
> update for Cordova tools + all platforms, or because you don't want to
> change the existing Cordova logic (and if the latter, what's your concern)?
>
> Have you had any inspiration about how to fix Ripple to avoid tripping
> this? I've not been able to come up with a safe approach yet. On the other
> hand, the change in Cordova to avoid triggering this is very simple - just
> a pain that it requires releasing a bunch of updates.
>
> Tim
> 
> From: Jesse 
> Sent: Saturday, May 2, 2015 2:28 AM
> To: dev@cordova.apache.org
> Subject: Re: Cordova 5.0.0 "duplicate cordova" check breaks Ripple
>
> I think ripple will need to change, I'll have a look and see if there is a
> more elegant way to implement honeypot.
>
>
>
> > On Apr 30, 2015, at 7:06 PM, Tim Barham 
> wrote:
> >
> > Hey everyone - a bug was filed today against Ripple that it is broken
> with
> > Cordova 5.0.0. The issue is that Ripple triggers the new "duplicate
> > cordova" check:
> >
> > cordova-js/src/cordova.js line 22:
> > if ("cordova" in window) { throw new Error("cordova already
> defined"); };
> >
> > Ripple patches cordova by defining a setter for window.cordova to
> > intercept it being created. This is sufficient to make ("cordova" in
> > window) return true. I don't see a way to readily resolve this issue in
> > Ripple. We can fix it in Cordova by changing the test to:
> >
> >   if (window.cordova) ...
> >
> > Couple of questions:
> > 1. Any reason not to make this change?
> > 2. To get this fix out will require re-releasing all platforms, correct?
> > And I presume a tools release to update the pinned platforms? Is this
> > sufficient reason to trigger such a release?
> >
> > Thanks!
> >
> > Tim
>
> -
> 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 5.0.0 "duplicate cordova" check breaks Ripple

[Jesse]

Discussions aside, are you in a position to test ripple?

I believe this change will fix it, can you try this change, and I will look
into the ripple side shortly?
https://github.com/apache/cordova-js/pull/109

We can start the re-release fanfare in the morning, as a minor release
directly from the last release and a minor bump with no other changes
coming in.

Let me know if there are still issues in cordova-js, and I'll look later
tonite.

Cheers,
   Jesse




@purplecabbage
risingj.com

On Mon, May 4, 2015 at 5:23 PM, Tim Barham  wrote:

> Thanks Jesse...
>
> > but still it will be at least a week before we can get a new everything
> out
>
> And the alternatives will take less than a week? :)
>
> While I agree there may be better ways for Ripple to "do it's thing", my
> immediate concern is to get Ripple working as quickly as possible. If we
> can indeed kill those two birds with one stone, that's great, but I'm
> worried that anything beyond a simple fix will drag out for quite a while.
>
> Also, I was picturing these sorts of changes as being part of proper
> plugin simulation support built into Cordova (that is, the ongoing project
> I've mentioned previously) - I wonder if for now we should just fix this
> the quickest way we can, and make sure the appropriate, public, documented
> hooks are in place as part of that project.
>
> > override the entire cordova object
>
> BTW, I guess you already know this, but to make sure it is clear - Ripple
> doesn't override the cordova object - it only overrides cordova/exec. It
> intercepts the creation of the cordova property so it can immediately patch
> cordova/exec before it can get called by anyone. It seems to me that
> patching cordova/exec is pretty fundamental to how Ripple works, but if
> there was another way it could ensure the correct timing (that is, patch
> cordova/exec after the cordova object is created, but before it can ever
> get called), that would probably suffice.
>
> I don't think cordova/exec/proxy is going to be a viable solution (at
> least as it currently works) - isn't there the risk that that will get
> overridden by plugins themselves? Also, Ripple wants to intercept *any*
> cordova.exec call, even ones it doesn't know about (so it can display UI to
> handle those cases) - how to we handle that using cordova/exec/proxy?
>
> Thanks for looking into this, BTW.
>
> Tim
>
> 
> From: Jesse 
> Sent: Tuesday, May 5, 2015 9:57 AM
> To: dev@cordova.apache.org
> Subject: Re: Cordova 5.0.0 "duplicate cordova" check breaks Ripple
>
> Yeah, my reasoning is that it is difficult to update all the affected bits
> in cordova.  We can change the cordova logic, but still it will be at least
> a week before we can get a new everything out.
>
> Part of my reasoning is that ripple claims to be a '... platform agnostic
> mobile application development and testing tool.' We should make that part
> true as well.
>
> Personally, I consider ripple's use of 'cordova' to be risky given that we
> have certain expectations of how our own library works, which may or may
> not be private to cordova.  I would much rather see ripple implement a
> ripple-cordova connector class which uses cordova/exec/proxy or some
> cordova apis that we purposely publish, which is what I plan to look into
> this week. Or we can consider moving to a model where we do define a way to
> override the entire cordova object, and document it.
>
>
> @purplecabbage
> risingj.com
>
> On Mon, May 4, 2015 at 3:56 PM, Tim Barham 
> wrote:
>
> > Hey Jesse - is your reasoning behind that to avoid having to release an
> > update for Cordova tools + all platforms, or because you don't want to
> > change the existing Cordova logic (and if the latter, what's your
> concern)?
> >
> > Have you had any inspiration about how to fix Ripple to avoid tripping
> > this? I've not been able to come up with a safe approach yet. On the
> other
> > hand, the change in Cordova to avoid triggering this is very simple -
> just
> > a pain that it requires releasing a bunch of updates.
> >
> > Tim
> > 
> > From: Jesse 
> > Sent: Saturday, May 2, 2015 2:28 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Cordova 5.0.0 "duplicate cordova" check breaks Ripple
> >
> > I think ripple will need to change, I'll have a look and see if there is
> a
> > more elegant way to implement honeypot.
> >
> >
> >
> > > On Apr 30, 2015, at 7:06 PM, Tim Barham 
> > wrote:
> >

Re: Also moving to a new team

[Jesse]

Congrats Andrew!
Best of luck in your new role, don't be a stranger.

Cheers,
  Jesse

@purplecabbage
risingj.com

On Tue, May 5, 2015 at 10:28 AM, Michael Brooks 
wrote:

> Congrats Andrew and best of luck on the new project!
>
> On Tue, May 5, 2015 at 9:35 AM, Nikhil Khandelwal 
> wrote:
>
> > All the best, Andrew! Thanks for being so responsive and taking a look at
> > so many of my PRs!
> >
> > Thanks,
> > Nikhil
> >
> >
> > -Original Message-
> > From: Murat Sutunc [mailto:mura...@microsoft.com]
> > Sent: Tuesday, May 5, 2015 9:26 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Also moving to a new team
> >
> > Best of luck on your new team Andrew! It's been a pleasure working with
> > you.
> >
> > -Original Message-
> > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
> > Grieve
> > Sent: Tuesday, May 5, 2015 8:16 AM
> > To: dev
> > Subject: Also moving to a new team
> >
> > As with Michal, you'll be seeing less of me around. My new full-time
> > project will be on the Android port of Chrome.
> >
> > Just want to make it clear that us moving to new teams has nothing to do
> > with a lack of faith in the project, but rather is due to needing a
> change
> > of scenery and exciting new projects becoming available here.
> >
> > I'm super excited to see a new wave of committers joining the project!
> The
> > momentum has certainly picked up:
> > - Cordova-android 4.0.0 was huge
> > - Plugins to npm was huge
> > - Win10 and wkwebview will be massive launches as well!
> >
> > Great time for Cordova! (or a bad one... you know... if you're measuring
> > against the goal of becoming obsolete :P)
> >
> > -
> > 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: Plugins release prep: Cherry-picking plugin updates

[Jesse]

+ file-transfer so we can resolve CB-8951


@purplecabbage
risingj.com

On Tue, May 5, 2015 at 12:19 PM, Steven Gill  wrote:

> Hey guys,
>
> I can help you out. The process is designed for all plugins but it is
> pretty easy to do it for just a few. I've done it many times.
>
> If changes are on master, they shouldn't be incomplete. Any known problem
> with release the master branch of those plugins?
>
> We could cherry-pick, but it is just more work than probably required.
> Since we don't have release branches for plugins, just tags.
>
> If you guys merge changes into master, I can take over the release or at
> least tell you the parts to modify in the release process to make it work.
>
> -Steve
>
> On Tue, May 5, 2015 at 11:44 AM, Rob Paveza 
> wrote:
>
> > Hi all -
> >
> > I started a [discuss] thread about plugin updates last week, effectively
> > saying that we wanted to take four JIRA items which are causing problems
> > for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943.  Since Murat is a
> > committer, he's actually trying to do the release.  We're looking at
> > device-motion, dialogs, vibration, and camera.
> >
> > However, as we go through the [release process](
> >
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md
> ),
> > there are a lot of things that give us pause, specifically that we're
> going
> > to end up tagging each plugin rather than just the four.  We're also
> > concerned that we'll bring in unstable or not-yet-completed changes from
> > 'master' in some of the plugins.  Instead, we're trying to cherry-pick.
> >
> > So, we know that where the final state is supposed to be:
> > - Each plugin that we're updating gets a new tag with a build-version
> bump
> > - The branch that we submitted as the PR should become the new tag (since
> > it was based on the previous release tag)
> > - Then we'll go on with the rest of the publish-to-NPM work, etc.
> >
> > Since all of the steps are automated, is there a straightforward way to
> > cherry-pick the individual pieces that is known and has been used before?
> > Or are we in new territory?
> >
> > Thanks!
> > -Rob and Murat
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: [GitHub] cordova-js pull request: CB-8674: Creates a 'cordova.env' object.....

[Jesse]

Looking. 



> On May 5, 2015, at 6:12 PM, nikhilkh  wrote:
> 
> Github user nikhilkh commented on the pull request:
> 
>https://github.com/apache/cordova-js/pull/108#issuecomment-99280031
> 
>LGTM. @purplecabbage - Thoughts?
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
> 
> -
> 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