Re: Nomination for a new chair for Apache Cordova

[Shazron]

 +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
>
>
>
>

[PMC] Password management for services we use

[Shazron]

Suggestion: https://github.com/1Password/1password-teams-open-source

Instead of putting passwords in a text file in the private PMC svn.

Re: [BOARD REPORT DRAFT] June 2019 Cordova Board Report

[Shazron]

LGTM

On Tue, Jun 11, 2019 at 10:50 AM Jesse  wrote:

> Bad link.
>
> https://github.com/apache/cordova-apache-board-reports/blob/master/2019/2019-06.md
>
> > On Jun 11, 2019, at 7:55 AM, Shazron  wrote:
> >
> > I don't think the PMC thing is correct. Was this generated in Whimsy? May
> > be a whimsy bug. I think we added Dave Alden and Tim Brust since Bryan
> > Ellis.
> >
> >> On Mon, Jun 10, 2019 at 11:30 PM Jesse  wrote:
> >>
> >> Please review and comment.
> >> https://github.com/apache/cordova-apache-board-reports
> >> /blob/master/2019/2019-06.md
> >> <
> >>
> https://github.com/apache/cordova-apache-board-reports/blob/master/2019/2019-03.md
> >>>
> >>
> >> Cheers,
> >>  Jesse
> >>
> >> @purplecabbage
> >> risingj.com
> >>
>

Re: [BOARD REPORT DRAFT] June 2019 Cordova Board Report

[Shazron]

I don't think the PMC thing is correct. Was this generated in Whimsy? May
be a whimsy bug. I think we added Dave Alden and Tim Brust since Bryan
Ellis.

On Mon, Jun 10, 2019 at 11:30 PM Jesse  wrote:

> Please review and comment.
> https://github.com/apache/cordova-apache-board-reports
> /blob/master/2019/2019-06.md
> <
> https://github.com/apache/cordova-apache-board-reports/blob/master/2019/2019-03.md
> >
>
> Cheers,
>   Jesse
>
> @purplecabbage
> risingj.com
>

Re: [DISCUSS] Node 6.x & 8.x Deprecation & Node 12.x Support

[Shazron]

+1000

On Wed, Apr 10, 2019 at 1:17 PM  wrote:

> Sounds reasonable and well thought out to me.
>
> Bryan Ellis  schrieb am Mi., 10. Apr. 2019, 09:42:
>
> > I would like to start the discussion around Cordova's planning for
> > deprecating Node 6.x and Node 8.x as well as starting to support Node
> 12.x.
> >
> > Since Node 6.x is being deprecated by the end of this month, I am not
> > expecting drastic action.
> >
> > Additionally, Node 8.x is expected to be deprecated by December.
> >
> > IMO, we could hold out till December to deprecate both versions and just
> > warn users about our recommendation to upgrade in the meantime. These
> > notices and warnings can be added in April and September as a patch or
> > minor release.
> >
> > As a side note, I suspect Android Q's release (August?) and possible iOS
> > (Sept?) to be out before December. For a major release for these new
> > platforms, adding Node will fall in nicely.
> >
> > Blog Post PR: https://github.com/apache/cordova-docs/pull/965
> > GH Issue Ticket: https://github.com/apache/cordova/issues/79
>

Re: [BOARD REPORT DRAFT] March 2019 Cordova Board Report

[Shazron]

This is correct (auto generated). All 3 were added on the same day, but the
system probably chose the first based on its sorting (alphabetical most
like).

On Tue, Mar 12, 2019 at 5:42 AM Chris Brody  wrote:

> I thought Ken was added after Bryan, may be mistaken though.
>
> On Mon, Mar 11, 2019 at 5:34 PM Jesse  wrote:
>
> > Please review and comment.
> >
> >
> https://github.com/apache/cordova-apache-board-reports/blob/master/2019/2019-03.md
> >
> > Cheers,
> >   Jesse
> >
>

Re: So....how did this happen? (Git commit weirdness)

[Shazron]

IMO I would generally avoid this type of thing unless it was a really
significant change (the change seems trivial).


On Tue, Feb 12, 2019 at 4:09 AM Chris Brody  wrote:

> I listed you as a co-author since you authored some of the changes
> included in the commit. I hope it is OK.
>
> On Mon, Feb 11, 2019 at 3:03 PM Joe Bowser  wrote:
> >
> > I haven't worked on Cordova in months, but for some reason I'm appearing
> on
> > this commit:
> >
> >
> https://github.com/apache/cordova-android/commit/73692e60d81f49f148ba9f8b4bc230b2f4d968a4
> >
> > Can someone explain how this happened?
> >
> > Thanks
> >
> > Joe
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Transferring Cordova issues on GitHub

[Shazron]

Not sure what they think about installing Probot:
https://probot.github.io/apps/move/
Seems like a good compromise -- since we have write permissions for
the source and target repos.

On Wed, Jan 16, 2019 at 11:47 PM Chris Brody  wrote:
>
> Thanks guys. I completely get it that it is not possible to get what we
> want according to the existing combination of INFRA rules and GitHub
> behavior.
>
> I find this to be pretty bad for usability and am hopeful that we may be
> able to work towards a better solution, somehow. That is why I raised the
> INFRA issue in the first place.
>
> On Wed, Jan 16, 2019 at 10:43 AM julio cesar sanchez 
> wrote:
>
> > They have answered that they can transfer the issues we tell them to, but I
> > think it's easier/faster to just create a new one than creating an infra
> > ticket so they move it.
> >
> > El mié., 16 ene. 2019 a las 16:39, Chris Brody ()
> > escribió:
> >
> > > I already saw that in the GitHub docs. I raised the INFRA issue in hopes
> > > that we can find a solution, somehow.
> > >
> > > On Wed, Jan 16, 2019 at 10:33 AM Darryl Pogue 
> > wrote:
> > >
> > > > From the GitHub docs:
> > > > > To transfer an open issue to another repository, you must have admin
> > > > permissions on the repository the issue is in and the repository you're
> > > > transferring the issue to.
> > > >
> > > > I don't think there's anything INFRA can do to enable it, since repo
> > > > admin isn't something they'll provide :(
> > > >
> > > > On Wed, Jan 16, 2019 at 7:22 AM Chris Brody 
> > > wrote:
> > > > >
> > > > > Here is an example where I had to apply a clumsy workaround:
> > > > > https://github.com/apache/cordova/issues/68
> > > > >
> > > > > I submitted the following INFRA ticket:
> > > > > https://issues.apache.org/jira/browse/INFRA-17671
> > > >
> > > > -
> > > > 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-common@3.1.0 tools release

[Shazron]

+1

On Tue, Dec 25, 2018 at 2:47 AM Chris Brody  wrote:
>
> Please review and vote on this Tools Release by replying to this email
> (and keep discussion on the DISCUSS thread).
>
> Artifacts have been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/common-3.1.0/
>
> The packages were published from their corresponding git tags:
> cordova-common: 3.1.0 (2492998ea0)
>
> Upon a successful vote I will upload the archives to dist/, publish
> them to npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 72 hours (extra voting hours due to
> a major holiday)
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and
> subdependencies have Apache-compatible licenses
> * Ensured continuous build was green when repos were tagged
> * Ran cordova-mobile-spec on Android (known test failures noted in
> )
>
> -
> 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: Latest cordova-android version not in maven repository

[Shazron]

Uploading to bintray/maven is not required for a release, but it is a
nice to have that we have always relied on.
Since it is done post-release, perhaps we can have some automation
(cordova-status?) that checks for these things that can be overlooked.

On Mon, Dec 17, 2018 at 10:02 PM Jan Piotrowski  wrote:
>
> Any reason you skipped this documented release step?
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#android-only-uploading-to-bintray
>
> > Also can someone explain the use case for publishing on Maven?
>
> Cordova Android is made available via Bintray/Maven so it can be be
> required and used via that distribution method.
>
> -J
>
>
> Am Mo., 17. Dez. 2018 um 14:48 Uhr schrieb Chris Brody <
> chris.br...@gmail.com>:
>
> > I published the last 2 releases, don't have much time this week to look
> > into Maven. Any chance someone else can do this?
> >
> > Also can someone explain the use case for publishing on Maven?
> >
> > On Mon, Dec 17, 2018, 7:57 AM julio cesar sanchez  > wrote:
> >
> > > Not sure if we missed some step on latest cordova-android releases, or
> > > if somebody else is publishing after releases, but 7.1.3 and 7.1.4 are
> > > not available on maven.
> > >
> > > Latest is 7.1.2
> > > https://mvnrepository.com/artifact/org.apache.cordova/framework/7.1.2
> > >
> >

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

Re: Windows Cordova Platform for Desktop Application!!

[Shazron]

Sorry looks like Windows Store only

On Thu, Dec 13, 2018 at 11:25 AM Meraj Jilani 
wrote:

> Hi,
>
> I am trying to develop a cross platform windows desktop application. I went
> through different sites and found that Apache's Cordova platform is best to
> develop a cross platform hybrid application.
>
> I understand that Cordova can be used to develop WIndows 8.1/ windows 10
> store apps, but can I use Cordova platform to develop windows desktop
> application?
>
> Please suggest.
>
> Thanks in advance,
> Meraj
>

Re: [PR] "Create a Minimal Reproduction Repository or Sample"

[Shazron]

I feel to repro an issue all we need is:
1. config.xml
2. contents of the 'www' folder

This assumes that they've already `--save`d their platforms and
plugins, and we can just put it in a new project and run `cordova
prepare` to populate. We could even have a command (?) somehow to
package this up for attaching to a bug...


On Sat, Dec 1, 2018 at 2:34 AM Jan Piotrowski  wrote:
>
> Another PR that I polished a bit and is ready for feedback and
> reviews: "Create a Minimal Reproduction Repository or Sample"
>
> PR: https://github.com/apache/cordova-contribute/pull/6
> Preview: 
> https://github.com/apache/cordova-contribute/blob/0a582edd0857353ff8790cbe5e6560bbcb72e7a7/create-reproduction.md
>
> We will be able to use this to reply to GitHub issue and hopefully get
> more and better reproduction repos.
>
> -J
>
> -
> 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: [dev] Introduce ES6 classes or not?

[Shazron]

I'm in favor of whatever makes it easier to contribute, and if a
contributor uses classes and it was appropriate (like there could be
more than one instance of it), should be fine
On Sat, Dec 1, 2018 at 12:28 AM Gearóid M  wrote:
>
> I'm definitely in favour of using classes. Personally I find them easier to 
> read and write. We are already using them in at least one place, the 
> ProjectBuilder in cordova-android.[1] This came about from a refactor I did a 
> few months ago, and since we dropped support for Node 6, it made sense to me 
> to use a class. I don't think we need to go refactoring everything, but if 
> there are new features to be added, I would strongly favour using classes in 
> those cases.
>
> [1] 
> https://github.com/apache/cordova-android/blob/master/bin/templates/cordova/lib/builders/ProjectBuilder.js
>
> On Fri, 30 Nov 2018, at 15:49, Oliver Salzburg wrote:
> > I'm in favor of ES6 classes.
> >
> > But that doesn't mean that everything that _can_ be written with classes
> > should. Pick the right tool for the job.
> >
> > While you can achieve the same object structure by just extending the
> > prototype, classes have the benefit of keeping related code parts close
> > to each other. A class is usually defined in a single `class {}` block.
> > With prototype extensions that is not required and it can be a lot
> > harder to determine how an object is constructed.
> >
> > So, as a language feature, they might not provide any benefits, but from
> > a code point of view, I think there are several. I'd put some of that
> > syntactic sugar in my tea.
> >
> > On 2018-11-30 03:20, Chris Brody wrote:
> > > I was wondering what our sentiment should be about using ES6 classes?
> > >
> > > My own opinion in coming in a response email.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] cordova-node-xcode@1.0.1 release

[Shazron]

+1
On Mon, Dec 10, 2018 at 9:04 PM Chris Brody  wrote:
>
> I would like to publish cordova-node-xcode as xcode@1.0.1 later today,
> which moves pegjs to devDependencies, has Travis CI enabled, and some
> other minor fixes before starting 2.0.0-dev. This is in case we need
> the fixes for anything before we drop support for Node.js pre-6.0.
>
> Any objections?
>
> -
> 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: FILE_URI vs NATIVE_URI question (camera plugin)

[Shazron]

Seems to me we could simplify things to one type and let the developer
process what is returned whether file://, content:// or cdvfile://
On Fri, Nov 23, 2018 at 9:25 PM julio cesar sanchez
 wrote:
>
> So in Camera plugin you can choose FILE_URI or NATIVE_URI, but it's not
> clear to me what should each of those return.
> I found this old thread  but
> it's still unclear to me.
>
> Right now camera plugin in Android, it sometimes return a content:// url,
> other times it returns a file:// url, and other times an url without scheme
> (like /storage/emulated/0/DCIM/Camera)
>
> Might be even more, those are just the 3 types I found, but didn't try
> every possible case.
>
> Also, the Camera plugin in Android treat both as the same, so even if we
> consider both to be the same, we should decide which kind of url we will
> return, I don't think we should have three (or more) different url types on
> the same plugin.

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

Re: [DISCUSS] cordova-node-xcode@2.0.0 release

[Shazron]

+1
On Mon, Dec 10, 2018 at 7:22 AM Chris Brody  wrote:
>
> I would like to publish a new major release of cordova-node-xcode as
> xcode@2.0.0 with some changes discussed in
> .
>
> Any objections?
>
> Does anyone have any reason to delay a tools release?
>
> Any outstanding patches to land?
>
> If not, I will land the proposals I reviewed and start the release tomorrow.
>
> /cc Laurin Quast who contributed some recent updates and fixes.
>
> -
> 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

[BOARD REPORT DRAFT] Dec 2018 Cordova Board Report

[Shazron]

Please review and comment:
https://github.com/apache/cordova-apache-board-reports/blob/master/2018/2018-12.md

I want to get this out before the end of this week. Thanks!

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

Re: Nomination for a new chair for Apache Cordova

[Shazron]

Now, now -- there's plenty of money in open source, that's why!
See https://www.youtube.com/watch?v=PyeWRd7ZEBs
On Tue, Dec 11, 2018 at 6:27 PM Jesse  wrote:
>
> Thank you Shazron for your continuous and unwavering commitment to
> Apache Cordova, you leave heavy shoes to fill and I am not only
> grateful to have walked all this way beside you, but to have you walk
> beside me for the next stretch
>
> I am deeply honored by the support I have seen (and felt) in this
> thread and graciously accept this nomination.
> I'll continued to do my best for both Cordova and Apache.
>
> In homage to Shaz, Ill close with
>   .. my gratitude in an 80's song - a classic by the Pet Shop Boys and
> Dusty Springfield:
> https://www.youtube.com/watch?v=Wn9E5i7l-Eg
>
> > On Dec 10, 2018, at 7:27 PM, Shazron  wrote:
> >> http://www.apache.org/dev/pmc.html#newchair
> >> On Tue, Dec 11, 2018 at 11:26 AM Shazron  wrote:
> >>
> >> Thank  you everyone.
> >> It looks like we have consensus (and votes by PMC members).
> >> 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 19, 2018
> >>
> >>
> >> -
> >>
> >> ## Resolution to change the chair of a project
> >>
> >>   A. Change the Apache Cordova Project Chair
> >>
> >>  WHEREAS, the Board of Directors heretofore appointed Shazron Abdullah 
> >> (shazron) to the office of Vice President, Apache Cordova, and
> >>
> >>  WHEREAS, the Board of Directors is in receipt of the resignation
> >>  of Shazron Abdullah 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 Jesse MacFadyen 
> >> (purplecabbage) as
> >>  the successor to the post;
> >>
> >>  NOW, THEREFORE, BE IT RESOLVED, that Shazron Abdullah is relieved and
> >>  discharged from the duties and responsibilities of the office
> >>  of Vice President, Apache Cordova, and
> >>
> >>  BE IT FURTHER RESOLVED, that Jesse MacFadyen 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 Mon, Dec 10, 2018 at 9:56 AM Simon MacDonald 
> >>>  wrote:
> >>>
> >>> +1 to Jesse taking over as chair. Also, thanks for everything you've done
> >>> for Apache Cordova over the years Shaz.
> >>>
> >>> Simon Mac Donald
> >>> http://simonmacdonald.com
> >>>
> >>>
> >>>> On Thu, Dec 6, 2018 at 9:30 PM Shazron  wrote:
> >>>>
> >>>> Hello beloved Community!
> >>>> I have been the chair of Apache Cordova since around April 2014 (~4.5
> >>>> years).
> >>>>
> >>>> The duties are 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. I have decided to resign my
> >>>> duties as the Apache Cordova chair, hopefully for the upcoming new
> >>>> year of 2019.
> >>>>
> >>>> I nominate Jesse MacFadyen as the next chair. Jesse has been with me
> >>>> at the start when Cordova was PhoneGap. Although we didn't give birth
> >>>> to it, we helped work on improving Cordova from being an infant to
> >>>> adulthood (together with our great team), particularly on cordova-ios.
> >>>> 10 years is adulthood in software!
> >>>>
> >>>> He has also contributed greatly to the other platforms and tooling,
> >>>> particularly cordova-windows. He has the most experience with helping
> >>>> run the Cordova project out of the remaining active contributors.
> >>>>
> >>>> As an Apache Member (https://www.apache.org/foundation/members.html)
> >>>>

Re: Nomination for a new chair for Apache Cordova

[Shazron]

http://www.apache.org/dev/pmc.html#newchair
On Tue, Dec 11, 2018 at 11:26 AM Shazron  wrote:
>
> Thank  you everyone.
> It looks like we have consensus (and votes by PMC members).
> 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 19, 2018
>
>
> -
>
> ## Resolution to change the chair of a project
>
> A. Change the Apache Cordova Project Chair
>
>    WHEREAS, the Board of Directors heretofore appointed Shazron Abdullah 
> (shazron) to the office of Vice President, Apache Cordova, and
>
>WHEREAS, the Board of Directors is in receipt of the resignation
>of Shazron Abdullah 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 Jesse MacFadyen 
> (purplecabbage) as
>    the successor to the post;
>
>NOW, THEREFORE, BE IT RESOLVED, that Shazron Abdullah is relieved and
>discharged from the duties and responsibilities of the office
>of Vice President, Apache Cordova, and
>
>BE IT FURTHER RESOLVED, that Jesse MacFadyen 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 Mon, Dec 10, 2018 at 9:56 AM Simon MacDonald  
> wrote:
> >
> > +1 to Jesse taking over as chair. Also, thanks for everything you've done
> > for Apache Cordova over the years Shaz.
> >
> > Simon Mac Donald
> > http://simonmacdonald.com
> >
> >
> > On Thu, Dec 6, 2018 at 9:30 PM Shazron  wrote:
> >
> > > Hello beloved Community!
> > > I have been the chair of Apache Cordova since around April 2014 (~4.5
> > > years).
> > >
> > > The duties are 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. I have decided to resign my
> > > duties as the Apache Cordova chair, hopefully for the upcoming new
> > > year of 2019.
> > >
> > > I nominate Jesse MacFadyen as the next chair. Jesse has been with me
> > > at the start when Cordova was PhoneGap. Although we didn't give birth
> > > to it, we helped work on improving Cordova from being an infant to
> > > adulthood (together with our great team), particularly on cordova-ios.
> > > 10 years is adulthood in software!
> > >
> > > He has also contributed greatly to the other platforms and tooling,
> > > particularly cordova-windows. He has the most experience with helping
> > > run the Cordova project out of the remaining active contributors.
> > >
> > > As an Apache Member (https://www.apache.org/foundation/members.html)
> > > he also understands and helps uphold 'The Apache Way'
> > > (https://www.apache.org/foundation/how-it-works.html) and will be a
> > > great liaison with the Board.
> > >
> > > I'm not going anywhere and I will still contribute to the project in
> > > my areas of expertise.
> > >
> > > Thank you.
> > >
> > > -
> > > 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: Nomination for a new chair for Apache Cordova

[Shazron]

Thank  you everyone.
It looks like we have consensus (and votes by PMC members).
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 19, 2018


-

## Resolution to change the chair of a project

A. Change the Apache Cordova Project Chair

   WHEREAS, the Board of Directors heretofore appointed Shazron
Abdullah (shazron) to the office of Vice President, Apache Cordova,
and

   WHEREAS, the Board of Directors is in receipt of the resignation
   of Shazron Abdullah 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 Jesse MacFadyen
(purplecabbage) as
   the successor to the post;

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

   BE IT FURTHER RESOLVED, that Jesse MacFadyen 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 Mon, Dec 10, 2018 at 9:56 AM Simon MacDonald
 wrote:
>
> +1 to Jesse taking over as chair. Also, thanks for everything you've done
> for Apache Cordova over the years Shaz.
>
> Simon Mac Donald
> http://simonmacdonald.com
>
>
> On Thu, Dec 6, 2018 at 9:30 PM Shazron  wrote:
>
> > Hello beloved Community!
> > I have been the chair of Apache Cordova since around April 2014 (~4.5
> > years).
> >
> > The duties are 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. I have decided to resign my
> > duties as the Apache Cordova chair, hopefully for the upcoming new
> > year of 2019.
> >
> > I nominate Jesse MacFadyen as the next chair. Jesse has been with me
> > at the start when Cordova was PhoneGap. Although we didn't give birth
> > to it, we helped work on improving Cordova from being an infant to
> > adulthood (together with our great team), particularly on cordova-ios.
> > 10 years is adulthood in software!
> >
> > He has also contributed greatly to the other platforms and tooling,
> > particularly cordova-windows. He has the most experience with helping
> > run the Cordova project out of the remaining active contributors.
> >
> > As an Apache Member (https://www.apache.org/foundation/members.html)
> > he also understands and helps uphold 'The Apache Way'
> > (https://www.apache.org/foundation/how-it-works.html) and will be a
> > great liaison with the Board.
> >
> > I'm not going anywhere and I will still contribute to the project in
> > my areas of expertise.
> >
> > Thank you.
> >
> > -
> > 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

[Shazron]

Hello beloved Community!
I have been the chair of Apache Cordova since around April 2014 (~4.5 years).

The duties are 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. I have decided to resign my
duties as the Apache Cordova chair, hopefully for the upcoming new
year of 2019.

I nominate Jesse MacFadyen as the next chair. Jesse has been with me
at the start when Cordova was PhoneGap. Although we didn't give birth
to it, we helped work on improving Cordova from being an infant to
adulthood (together with our great team), particularly on cordova-ios.
10 years is adulthood in software!

He has also contributed greatly to the other platforms and tooling,
particularly cordova-windows. He has the most experience with helping
run the Cordova project out of the remaining active contributors.

As an Apache Member (https://www.apache.org/foundation/members.html)
he also understands and helps uphold 'The Apache Way'
(https://www.apache.org/foundation/how-it-works.html) and will be a
great liaison with the Board.

I'm not going anywhere and I will still contribute to the project in
my areas of expertise.

Thank you.

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

Re: vote duration discrepancy

[Shazron]

FWIW the only reference I see for an emergency (security) patch vote
is here: https://httpd.apache.org/dev/voting.html#emergency for the
HTTP Server project.
However, that document is deemed obsolete. I believe it has been
superseded by the Security patch release process.
On Fri, Sep 28, 2018 at 11:41 PM Shazron  wrote:
>
> To be honest I didn't expect the vote to end so fast especially with
> the notice "Voting will go on for a minimum of 48 hours." in the vote
> thread itself.
> If this was expressed as a duration of 24 hours and expressed as an
> emergency (I know it was implied, but for some rules are rules), I
> think we would have been fine with that -- but the vote did say 48
> hours.On Fri, Sep 28, 2018 at 11:35 PM Shazron 
> wrote:
> >
> > Jesse sums up what I would have said. We all agreed on the 48 hours
> > (somewhere way back), especially with our project with 60+ repos where
> > we were changing rapidly (not so much now of course), and 72 hours was
> > too late for a release.
> >
> > 48 seems to be a good midpoint for the rule to include people from all
> > geographic timezones. 72 hours would have been OK if we only had to do
> > one release, like the http server project (that was the genesis of the
> > foundation itself..)
> > On Fri, Sep 28, 2018 at 11:21 PM Jesse  wrote:
> > >
> > > These are guidelines. We make our own rules. The important part is that 
> > > we make sure we are inclusive of people all around the planet.
> > >
> > > A hotfix is a different situation, we need to get it out fast and since 
> > > it is not a significant change, a quick window should be fine.
> > >
> > > >  [1] ... Votes should generally be permitted to run for at least 72 
> > > > hours to provide an opportunity for all concerned persons to 
> > > > participate regardless of their geographic locations. ...
> > >
> > > ‘Generally’!
> > > We shortened this for releases at some point, there is probably a vote 
> > > thread back there somewhere.
> > >
> > > Note that 72 hours still applies to votes nominating new pmc/committers.
> > >
> > > Going deeper, I see a trend where we question process and rules. I find 
> > > this to be a distraction from the actual work. I am of the mind that we 
> > > are all trustworthy, able to constructively and openly discuss things and 
> > > this formality can be a barrier to moving forwards. Maybe newer 
> > > committers need clearer guidelines and I have just been around too long 
> > > to be objective, that is a possibility too.
> > >
> > > Cheers,
> > >   Jesse
> > >
> > > [1] 
> > > https://www.apache.org/foundation/votinhttps://www.apache.org/foundation/voting.html#ReleaseVotesg.html#ReleaseVotes
> > >
> > >
> > > > On Sep 28, 2018, at 1:56 AM, julio cesar sanchez 
> > > >  wrote:
> > > >
> > > > This is being discussed in slack and github
> > > > <https://github.com/apache/cordova-coho/issues/202>, but I think it 
> > > > belongs
> > > > to the mail list.
> > > >
> > > > There is a discrepancy in the duration of the votes.
> > > >
> > > > Apache states that:
> > > > Release votes SHOULD remain open for at least 72 hours.
> > > >
> > > > But in coho vote templates we have:
> > > > Voting will go on for a minimum of 48 hours.
> > > >
> > > > Also both of them say "at least" or "a minimum", but not sure if 
> > > > sometimes
> > > > there can be exceptions to speed things up.

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

Re: vote duration discrepancy

[Shazron]

To be honest I didn't expect the vote to end so fast especially with
the notice "Voting will go on for a minimum of 48 hours." in the vote
thread itself.
If this was expressed as a duration of 24 hours and expressed as an
emergency (I know it was implied, but for some rules are rules), I
think we would have been fine with that -- but the vote did say 48
hours.On Fri, Sep 28, 2018 at 11:35 PM Shazron 
wrote:
>
> Jesse sums up what I would have said. We all agreed on the 48 hours
> (somewhere way back), especially with our project with 60+ repos where
> we were changing rapidly (not so much now of course), and 72 hours was
> too late for a release.
>
> 48 seems to be a good midpoint for the rule to include people from all
> geographic timezones. 72 hours would have been OK if we only had to do
> one release, like the http server project (that was the genesis of the
> foundation itself..)
> On Fri, Sep 28, 2018 at 11:21 PM Jesse  wrote:
> >
> > These are guidelines. We make our own rules. The important part is that we 
> > make sure we are inclusive of people all around the planet.
> >
> > A hotfix is a different situation, we need to get it out fast and since it 
> > is not a significant change, a quick window should be fine.
> >
> > >  [1] ... Votes should generally be permitted to run for at least 72 hours 
> > > to provide an opportunity for all concerned persons to participate 
> > > regardless of their geographic locations. ...
> >
> > ‘Generally’!
> > We shortened this for releases at some point, there is probably a vote 
> > thread back there somewhere.
> >
> > Note that 72 hours still applies to votes nominating new pmc/committers.
> >
> > Going deeper, I see a trend where we question process and rules. I find 
> > this to be a distraction from the actual work. I am of the mind that we are 
> > all trustworthy, able to constructively and openly discuss things and this 
> > formality can be a barrier to moving forwards. Maybe newer committers need 
> > clearer guidelines and I have just been around too long to be objective, 
> > that is a possibility too.
> >
> > Cheers,
> >   Jesse
> >
> > [1] 
> > https://www.apache.org/foundation/votinhttps://www.apache.org/foundation/voting.html#ReleaseVotesg.html#ReleaseVotes
> >
> >
> > > On Sep 28, 2018, at 1:56 AM, julio cesar sanchez  
> > > wrote:
> > >
> > > This is being discussed in slack and github
> > > <https://github.com/apache/cordova-coho/issues/202>, but I think it 
> > > belongs
> > > to the mail list.
> > >
> > > There is a discrepancy in the duration of the votes.
> > >
> > > Apache states that:
> > > Release votes SHOULD remain open for at least 72 hours.
> > >
> > > But in coho vote templates we have:
> > > Voting will go on for a minimum of 48 hours.
> > >
> > > Also both of them say "at least" or "a minimum", but not sure if sometimes
> > > there can be exceptions to speed things up.

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

Re: vote duration discrepancy

[Shazron]

Jesse sums up what I would have said. We all agreed on the 48 hours
(somewhere way back), especially with our project with 60+ repos where
we were changing rapidly (not so much now of course), and 72 hours was
too late for a release.

48 seems to be a good midpoint for the rule to include people from all
geographic timezones. 72 hours would have been OK if we only had to do
one release, like the http server project (that was the genesis of the
foundation itself..)
On Fri, Sep 28, 2018 at 11:21 PM Jesse  wrote:
>
> These are guidelines. We make our own rules. The important part is that we 
> make sure we are inclusive of people all around the planet.
>
> A hotfix is a different situation, we need to get it out fast and since it is 
> not a significant change, a quick window should be fine.
>
> >  [1] ... Votes should generally be permitted to run for at least 72 hours 
> > to provide an opportunity for all concerned persons to participate 
> > regardless of their geographic locations. ...
>
> ‘Generally’!
> We shortened this for releases at some point, there is probably a vote thread 
> back there somewhere.
>
> Note that 72 hours still applies to votes nominating new pmc/committers.
>
> Going deeper, I see a trend where we question process and rules. I find this 
> to be a distraction from the actual work. I am of the mind that we are all 
> trustworthy, able to constructively and openly discuss things and this 
> formality can be a barrier to moving forwards. Maybe newer committers need 
> clearer guidelines and I have just been around too long to be objective, that 
> is a possibility too.
>
> Cheers,
>   Jesse
>
> [1] 
> https://www.apache.org/foundation/votinhttps://www.apache.org/foundation/voting.html#ReleaseVotesg.html#ReleaseVotes
>
>
> > On Sep 28, 2018, at 1:56 AM, julio cesar sanchez  
> > wrote:
> >
> > This is being discussed in slack and github
> > , but I think it belongs
> > to the mail list.
> >
> > There is a discrepancy in the duration of the votes.
> >
> > Apache states that:
> > Release votes SHOULD remain open for at least 72 hours.
> >
> > But in coho vote templates we have:
> > Voting will go on for a minimum of 48 hours.
> >
> > Also both of them say "at least" or "a minimum", but not sure if sometimes
> > there can be exceptions to speed things up.

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

Re: [iOS] State of Xcode 10 support

[Shazron]

I think we should just bake in this build flag (implicitly) for the
next cordova-ios release, in the interim. I haven't tested on Xcode 9
whether this will cause problems on the command line, I hope not.
On Sat, Sep 15, 2018 at 1:26 AM Darryl Pogue  wrote:
>
> A few issues have started to come in regarding the state of Cordova
> projects on Xcode 10. This is a rough summary of the situation:
>
> Xcode 10 uses a new build system by default (previously available on
> an opt-in basis in Xcode 9). The cordova-ios project structure is not
> compatible with this new build system and results in failures.
> Officially, we do not claim to support Xcode 10.
>
> Currently the best workaround is to opt-out of the new build system.
> Users can do this by specifying
> `--buildFlag="-UseModernBuildSystem=0"` on the command line, or adding
> the following to build.json under the ios key:
>
> "buildFlag": [
>   "-UseModernBuildSystem=0"
> ]
>
>
> I would like to investigate what is required to get a cordova-ios
> project building with the new build system, and (if the changes are
> reasonable) try to get a fix into the next major for
> cordova-ios@5.0.0. Going to try to get a coworker to help me poke at
> this over the next week or so.
>
> Once that's done, we can evaluate the possibility of backporting to a
> 4.x release, but I consider that low priority given that Xcode 9 will
> still be usable for another year and there's a relatively easy
> workaround to use the old build system.
>
> -
> 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: [BOARD REPORT DRAFT] Sept 2018 Cordova Board Report

[Shazron]

I think we shouldn't base anything on _now_ so we don't have a moving target.
In any case, we just have to choose one method, and what we choose we
can just cache a snapshot of it, consistently, to mark possible
trends.
I used to compile stats manually but abandoned it:
https://github.com/apache/cordova-apache-board-reports/blob/master/2014/stats.json
On Thu, Sep 20, 2018 at 6:19 PM Jan Piotrowski  wrote:
>
> Yes, "reading" those numbers is unfortunately not trivial - I had to
> rewrite those queries _a lot_ until they made some sense without knots
> in my brain.
>
> Here is the explanation for what you see:
>
> > Referring to Sept Q3.
> >
> > Issues created - 103 open, 62 closed --> 165 total issues created
> > Issues closed -   53 closed --> 9 issues less from 62 above
>
> Issues created: In Q3 a total of 165 issues were created. Of those
> 165, _right now_ 103 are open and 62 are closed.
> Issues closed: In Q3 a total of 53 issues were closed (although those
> could have been created in Q3, Q2, Q1...)
>
> > PRs created - 51 open, 257 closed/merged -->  308 total PRs created
> > PRs closed/merged - 299 closed/merged --> 9 issues less from 308 above
>
> Same for PRs:
> PRs created: In Q3 a total of 308 PRs were created. Of those 308,
> _right now_ 51 are still open and 257 are closed/merged.
> PRs closed/merged: In Q3 a total of 299 PRs were closed/merged
> (although those could have been created any time in the past)
>
> The "created" query chooses items based on their `created` date, the
> "closed" query based on `closed` date.
>
> Maybe the open/closed for the "created" queries should not be
> considered, as it is based on _now_ and can change over time (when
> more of those items are closed as time progresses).
> (On the other hand: It can be useful to know how many of the new items
> are already taken care of already.)
>
> Does that make sense?
> Or should we have different queries?
> Any idea how to better represent and document the current situation?
>
> J
>
> 2018-09-17 3:36 GMT+02:00 Shazron :
> > Copy pasta mistake. Should be:
> > PRs closed/merged - 299 closed/merged --> 9 issues less from 308 above
> > On Mon, Sep 17, 2018 at 9:36 AM Shazron  wrote:
> >>
> >> Thanks Jan!
> >> Some issues with the queries, the math doesn't add up.
> >>
> >> Referring to Sept Q3.
> >>
> >> Issues created - 103 open, 62 closed --> 165 total issues created
> >> Issues closed -   53 closed --> 9 issues less from 62 above
> >>
> >> PRs created - 51 open, 257 closed/merged -->  308 total PRs created
> >> PRs closed/merged - 299 closed/merged --> 9 issues less from 62 above
> >>
> >> The small discrepancy is no big deal for now -- I'll take the stats from 
> >> the 'Created' query for the board report.
> >> On Sat, Sep 15, 2018 at 2:32 AM Jan Piotrowski  
> >> wrote:
> >> >
> >> > http://cordova.betamo.de/cordova-board-reports-issue-and-pr-searches.php
> >> > now exists and displays for multiple quarters (past and present) links
> >> > to GitHub searches that show:
> >> >
> >> > - Issues created in quarter (displays individually how many of those
> >> > still open and how many closed)
> >> > - Issues closed in quarter
> >> > - PRs created in quarter (displays individually how many of those
> >> > still open and how many closed/merged)
> >> > - PRs merged in quarter
> >> > - PRs closed in quarter
> >> > - PRs closed or merged in quarter
> >> >
> >> > Anything missing?
> >> > Please check my queries an logic - I might have a knot in my brain now
> >> > from the unmerged/closed/merged stuff now.
> >> >
> >> > It might be worth reporting "open issues and open PRs right now", but
> >> > I was not able to think how to build this in a search query for any
> >> > point of time. Anyone an idea?
> >> >
> >> > -J
> >> >
> >> > 2018-09-14 18:56 GMT+02:00 Shazron :
> >> > > Let's get this process down right for next quarter, if we don't get it
> >> > > in time for this one.
> >> > > Yes, the reporting dates are in the README for tge repo for the draft 
> >> > > report.
> >> > > On Fri, Sep 14, 2018 at 7:32 PM Jan Piotrowski  
> >> > > wrote:
> >> > >>
> >> > >> Thanks for pulling me in here julio.
> >> > >>
> >&g

Re: [BOARD REPORT DRAFT] Sept 2018 Cordova Board Report

[Shazron]

Copy pasta mistake. Should be:
PRs closed/merged - 299 closed/merged --> 9 issues less from 308 above
On Mon, Sep 17, 2018 at 9:36 AM Shazron  wrote:
>
> Thanks Jan!
> Some issues with the queries, the math doesn't add up.
>
> Referring to Sept Q3.
>
> Issues created - 103 open, 62 closed --> 165 total issues created
> Issues closed -   53 closed --> 9 issues less from 62 above
>
> PRs created - 51 open, 257 closed/merged -->  308 total PRs created
> PRs closed/merged - 299 closed/merged --> 9 issues less from 62 above
>
> The small discrepancy is no big deal for now -- I'll take the stats from the 
> 'Created' query for the board report.
> On Sat, Sep 15, 2018 at 2:32 AM Jan Piotrowski  wrote:
> >
> > http://cordova.betamo.de/cordova-board-reports-issue-and-pr-searches.php
> > now exists and displays for multiple quarters (past and present) links
> > to GitHub searches that show:
> >
> > - Issues created in quarter (displays individually how many of those
> > still open and how many closed)
> > - Issues closed in quarter
> > - PRs created in quarter (displays individually how many of those
> > still open and how many closed/merged)
> > - PRs merged in quarter
> > - PRs closed in quarter
> > - PRs closed or merged in quarter
> >
> > Anything missing?
> > Please check my queries an logic - I might have a knot in my brain now
> > from the unmerged/closed/merged stuff now.
> >
> > It might be worth reporting "open issues and open PRs right now", but
> > I was not able to think how to build this in a search query for any
> > point of time. Anyone an idea?
> >
> > -J
> >
> > 2018-09-14 18:56 GMT+02:00 Shazron :
> > > Let's get this process down right for next quarter, if we don't get it
> > > in time for this one.
> > > Yes, the reporting dates are in the README for tge repo for the draft 
> > > report.
> > > On Fri, Sep 14, 2018 at 7:32 PM Jan Piotrowski  
> > > wrote:
> > >>
> > >> Thanks for pulling me in here julio.
> > >>
> > >> http://cordova.betamo.de/cordova-github-issues-search-strings.php
> > >> creates the search strings for all issues on all repositories (bottom
> > >> left).
> > >>
> > >> Just adding the time frame doesn't work, with `created:>2018-06-01
> > >> created:<2018-09-01` added at the end, it seems the second `created`
> > >> is overwriting the first one and returns all issues until 09-01.
> > >>
> > >> But you can exclude all before and after the relevant dates with
> > >> `-created:<2018-06-01 -created:>2018-09-01`:
> > >> https://github.com/issues?utf8=%E2%9C%93=is%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hel

Re: [BOARD REPORT DRAFT] Sept 2018 Cordova Board Report

[Shazron]

Thanks Jan!
Some issues with the queries, the math doesn't add up.

Referring to Sept Q3.

Issues created - 103 open, 62 closed --> 165 total issues created
Issues closed -   53 closed --> 9 issues less from 62 above

PRs created - 51 open, 257 closed/merged -->  308 total PRs created
PRs closed/merged - 299 closed/merged --> 9 issues less from 62 above

The small discrepancy is no big deal for now -- I'll take the stats
from the 'Created' query for the board report.
On Sat, Sep 15, 2018 at 2:32 AM Jan Piotrowski  wrote:
>
> http://cordova.betamo.de/cordova-board-reports-issue-and-pr-searches.php
> now exists and displays for multiple quarters (past and present) links
> to GitHub searches that show:
>
> - Issues created in quarter (displays individually how many of those
> still open and how many closed)
> - Issues closed in quarter
> - PRs created in quarter (displays individually how many of those
> still open and how many closed/merged)
> - PRs merged in quarter
> - PRs closed in quarter
> - PRs closed or merged in quarter
>
> Anything missing?
> Please check my queries an logic - I might have a knot in my brain now
> from the unmerged/closed/merged stuff now.
>
> It might be worth reporting "open issues and open PRs right now", but
> I was not able to think how to build this in a search query for any
> point of time. Anyone an idea?
>
> -J
>
> 2018-09-14 18:56 GMT+02:00 Shazron :
> > Let's get this process down right for next quarter, if we don't get it
> > in time for this one.
> > Yes, the reporting dates are in the README for tge repo for the draft 
> > report.
> > On Fri, Sep 14, 2018 at 7:32 PM Jan Piotrowski  wrote:
> >>
> >> Thanks for pulling me in here julio.
> >>
> >> http://cordova.betamo.de/cordova-github-issues-search-strings.php
> >> creates the search strings for all issues on all repositories (bottom
> >> left).
> >>
> >> Just adding the time frame doesn't work, with `created:>2018-06-01
> >> created:<2018-09-01` added at the end, it seems the second `created`
> >> is overwriting the first one and returns all issues until 09-01.
> >>
> >> But you can exclude all before and after the relevant dates with
> >> `-created:<2018-06-01 -created:>2018-09-01`:
> >> https://github.com/issues?utf8=%E2%9C%93=is%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-contribute+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordova-p

Re: [BOARD REPORT DRAFT] Sept 2018 Cordova Board Report

[Shazron]

Let's get this process down right for next quarter, if we don't get it
in time for this one.
Yes, the reporting dates are in the README for tge repo for the draft report.
On Fri, Sep 14, 2018 at 7:32 PM Jan Piotrowski  wrote:
>
> Thanks for pulling me in here julio.
>
> http://cordova.betamo.de/cordova-github-issues-search-strings.php
> creates the search strings for all issues on all repositories (bottom
> left).
>
> Just adding the time frame doesn't work, with `created:>2018-06-01
> created:<2018-09-01` added at the end, it seems the second `created`
> is overwriting the first one and returns all issues until 09-01.
>
> But you can exclude all before and after the relevant dates with
> `-created:<2018-06-01 -created:>2018-09-01`:
> https://github.com/issues?utf8=%E2%9C%93=is%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-contribute+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordova-plugin-compat+repo%3Aapache%2Fcordova-registry-web+repo%3Aapache%2Fcordova-registry+repo%3Aapache%2Fcordova-fauxton-server+-created%3A%3C2018-06-01+-created%3A%3E2018-09-01+
> (via https://stackoverflow.com/a/50183610/252627)
>
> Is that what we are looking for?
>
> We can probably also search for "PRs closed in quarter" using
> https://help.github.com/articles/searching-issues-and-pull-requests/#search-by-when-an-issue-or-pull-request-was-closed
>
>
> If so, I can quickly add the generation of these search links to
> cordova.betamo.de as well. Our quarter starts in June, correct?
>
> J
>
> 2018-09-14 13:17 GMT+02:00 julio cesar sanchez :
> > Jan had some filters to easily see/list bugs, but not sure if it's possible
> > to know the number of created/closes issues by quarter.
> > Will put him in copy just in case he missed the draft and can chime in to
> > provide more information.
> >
> > El vie., 14 sept. 2018 a las 2:34, Shazron () escribió:
> >>
> >> What Julio said -- broad strokes only.
> >> Julio -- if we have those numbers, we could add them. Unless it's an
> >> automatic process, it won't be reliable.
> >> On Thu, Sep 13, 2018 at 7:35 PM julio cesar sanchez
> >>  wrote:
> >> >
> >> > I don't think that information is relevant for the report, as what we
> >> > usually include are releases and information about them, so it's
> >> > something
> >> > we should mention when we release the master changes, not before.
> >> >
> >> > As 

Re: [BOARD REPORT DRAFT] Sept 2018 Cordova Board Report

[Shazron]

What Julio said -- broad strokes only.
Julio -- if we have those numbers, we could add them. Unless it's an
automatic process, it won't be reliable.
On Thu, Sep 13, 2018 at 7:35 PM julio cesar sanchez
 wrote:
>
> I don't think that information is relevant for the report, as what we
> usually include are releases and information about them, so it's something
> we should mention when we release the master changes, not before.
>
> As the report talks about JIRA issues and we moved to github issues, should
> we add the number of github issues created/closed?
>
>
>
> El jue., 13 sept. 2018 a las 13:11, Chris Brody ()
> escribió:
>
> > There was a lot of work done on master branch for next major release in
> > areas such as performance improvements, internal API cleanup, migtation
> > away from shelljs, major test improvements that seem to be missing.
> >
> > On Thu, Sep 13, 2018, 12:14 AM Shazron  wrote:
> >
> > > Please review and comment
> > >
> > >
> > https://github.com/apache/cordova-apache-board-reports/blob/master/2018/2018-09.md
> > >
> > > I want to get this out before the end of this week. Thanks!
> > >
> > > -
> > > 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

[BOARD REPORT DRAFT] Sept 2018 Cordova Board Report

[Shazron]

Please review and comment
https://github.com/apache/cordova-apache-board-reports/blob/master/2018/2018-09.md

I want to get this out before the end of this week. Thanks!

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

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Shazron]

I think we have to take a look at whether we actually *will* look at
GH Issues *and* JIRA. This assumes that us, with limited time and
resources will actually do it.
I don't think I will, tbh. The issues are not lost, they are still in
JIRA for reference when the user wants to take it up again.

This is just declaring issue bankruptcy (a detached break, Cortés
burning his ships) and requiring the user to re-file if still relevant
(they get an email notification), and puts the onus on the user, for
them to have a stake in issues they have so that they can get
resolved. They must be part of this and care also, we can't babysit
everything. We are a technically a volunteer operation here, I think
it's too much for us to maintain two sources of issues. We already
have a lot on our plate already, IMO.

That being said, I will go with the consensus on this list (if we
believe we have consensus), and I will bring it up again in a few
months time to see where we are with JIRA, and I will do my best with
bridging the two personally.
On Thu, Aug 23, 2018 at 5:56 PM julio cesar sanchez
 wrote:
>
> Realistically, if they created an issue more than 6 months ago and nobody
> looked at it in that time, they wouldn't bother to recreate. So we would
> lose ~1700 issues.
>
> I agree with Raphael, if options are bulk close and ask for migration or
> keep them open, I vote for keeping them open.
>
> If somebody creates a new issue that is already in JIRA and we notice it,
> we can close the JIRA one as duplicate of the github one. (it has already
> happened in at least one issue that I have noticed)
>
> El jue., 23 ago. 2018 a las 11:42, Shazron () escribió:
>
> > Back of the napkin calculation... if we took 5 mins (which is quite
> > conservative) to migrate one by one, 1,811*5 = 9,055 minutes (or ~19
> > days of 8 hours a day full time). That's about a month of work for one
> > person (not including weekends), but realistically it will be greater
> > than this of course, definitely a few months. (of course the work can
> > be run in parallel with more people...)
> > On Thu, Aug 23, 2018 at 5:34 PM Shazron  wrote:
> > >
> > > Realistically doing it one by one will take a very long time, nor is
> > > it necessary -- as a volunteer or if you were paid by your employer.
> > > Some of these issues might be not relevant anymore. If it was
> > > relevant, they can re-file in GH. I really don't want this to drag out
> > > for another year.
> > >
> > > In my proposal - nothing will be moved, everything will be closed,
> > > with a note to re-file in GH if relevant. There will be no "dangling"
> > > issues - it's like what you've seen in some open sourced projects,
> > > "Closing this stale issue. Re-open if still relevant" (but we say
> > > re-file).
> > > On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez
> > >  wrote:
> > > >
> > > > I wouldn't do a bulk close neither, I think we should migrate them one
> > by
> > > > one to the respective github repo, even using same JIRA id so they
> > still
> > > > get linked, and then manually close as duplicate of the new github one.
> > > >
> > > > It's going to be a lot of work, but we don't need to do it right away,
> > we
> > > > can start by the latest ones and migrate a few every day until we
> > finish.
> > > > Would be good to actually try to reproduce them before migrating, so we
> > > > make sure it's still an issue, but as this will take even more time,
> > > > wouldn't make it mandatory.
> > > >
> > > >
> > > >
> > > > El jue., 23 ago. 2018 a las 11:06, Shazron ()
> > escribió:
> > > >
> > > > > Thanks Jan - I will hold off until we are ready of course.
> > > > >
> > > > > Raphael - close as in there can not be any more comments added or
> > > > > additions to the issue, not deletion. They will still exist and be
> > > > > searchable. We definitely can add a label when we close them.
> > > > > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski  > >
> > > > > wrote:
> > > > > >
> > > > > > Just a note to make sure: Please do not proceed with this before
> > issue
> > > > > > and PR templates are in place, labels are unified etc - meaning:
> > > > > > GitHub repos are ready.
> > > > > > (Working on this right now)
> > > > > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron <
> > shaz...@gmail.com>:
> > > > 

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Shazron]

Back of the napkin calculation... if we took 5 mins (which is quite
conservative) to migrate one by one, 1,811*5 = 9,055 minutes (or ~19
days of 8 hours a day full time). That's about a month of work for one
person (not including weekends), but realistically it will be greater
than this of course, definitely a few months. (of course the work can
be run in parallel with more people...)
On Thu, Aug 23, 2018 at 5:34 PM Shazron  wrote:
>
> Realistically doing it one by one will take a very long time, nor is
> it necessary -- as a volunteer or if you were paid by your employer.
> Some of these issues might be not relevant anymore. If it was
> relevant, they can re-file in GH. I really don't want this to drag out
> for another year.
>
> In my proposal - nothing will be moved, everything will be closed,
> with a note to re-file in GH if relevant. There will be no "dangling"
> issues - it's like what you've seen in some open sourced projects,
> "Closing this stale issue. Re-open if still relevant" (but we say
> re-file).
> On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez
>  wrote:
> >
> > I wouldn't do a bulk close neither, I think we should migrate them one by
> > one to the respective github repo, even using same JIRA id so they still
> > get linked, and then manually close as duplicate of the new github one.
> >
> > It's going to be a lot of work, but we don't need to do it right away, we
> > can start by the latest ones and migrate a few every day until we finish.
> > Would be good to actually try to reproduce them before migrating, so we
> > make sure it's still an issue, but as this will take even more time,
> > wouldn't make it mandatory.
> >
> >
> >
> > El jue., 23 ago. 2018 a las 11:06, Shazron () escribió:
> >
> > > Thanks Jan - I will hold off until we are ready of course.
> > >
> > > Raphael - close as in there can not be any more comments added or
> > > additions to the issue, not deletion. They will still exist and be
> > > searchable. We definitely can add a label when we close them.
> > > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski 
> > > wrote:
> > > >
> > > > Just a note to make sure: Please do not proceed with this before issue
> > > > and PR templates are in place, labels are unified etc - meaning:
> > > > GitHub repos are ready.
> > > > (Working on this right now)
> > > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron :
> > > > >
> > > > > I've done this for our JIRA:
> > > > > - I've changed "Resolved" issues to "Closed" (about 8000+ of them)
> > > > > - I've changed issues with "No Component" to the relevant component
> > > > >
> > > > > What's left:
> > > > > - We have 1881 Open, Reopened or In Progress issues
> > > > > - 474 were created in the last year (52 weeks)
> > > > > - thus 1,407 were created more than a year ago
> > > > > - 199 were created in the last 6 months (26 weeks)
> > > > >
> > > > > What's next:
> > > > > 1. I can Bulk Resolve all issues with a comment so the reporters will
> > > > > know where to re-file, with instructions, and point them to
> > > > > issues.cordova.io [FAST]
> > > > > OR
> > > > > 2. I can Bulk Resolve issues by component, and point them to the right
> > > > > GH repo to file the new issue [SLOW]
> > > > >
> > > > > Since this is a bulk operation, if we still need to keep some issues
> > > > > open in JIRA, we need to tag with a label so I can skip those.
> > > > >
> > > > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski 
> > > wrote:
> > > > > >
> > > > > > > 1. Should we just disable those then? One other way is to add in
> > > bold
> > > > > > > big letters about the deprecation in the New Issue template
> > > > > >
> > > > > > We should probably "just" define our deprecation and archival policy
> > > > > > (see other active thread). Depending on that, we can create another
> > > > > > INFRA issue to get taken care of that. There is no flood of Github
> > > > > > issues for these repos right now, so no harm done.
> > > > > >
> > > > > > > 2. These links are super useful. Perhaps they should be on the
> > > > > > > website, wh

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Shazron]

Realistically doing it one by one will take a very long time, nor is
it necessary -- as a volunteer or if you were paid by your employer.
Some of these issues might be not relevant anymore. If it was
relevant, they can re-file in GH. I really don't want this to drag out
for another year.

In my proposal - nothing will be moved, everything will be closed,
with a note to re-file in GH if relevant. There will be no "dangling"
issues - it's like what you've seen in some open sourced projects,
"Closing this stale issue. Re-open if still relevant" (but we say
re-file).
On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez
 wrote:
>
> I wouldn't do a bulk close neither, I think we should migrate them one by
> one to the respective github repo, even using same JIRA id so they still
> get linked, and then manually close as duplicate of the new github one.
>
> It's going to be a lot of work, but we don't need to do it right away, we
> can start by the latest ones and migrate a few every day until we finish.
> Would be good to actually try to reproduce them before migrating, so we
> make sure it's still an issue, but as this will take even more time,
> wouldn't make it mandatory.
>
>
>
> El jue., 23 ago. 2018 a las 11:06, Shazron () escribió:
>
> > Thanks Jan - I will hold off until we are ready of course.
> >
> > Raphael - close as in there can not be any more comments added or
> > additions to the issue, not deletion. They will still exist and be
> > searchable. We definitely can add a label when we close them.
> > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski 
> > wrote:
> > >
> > > Just a note to make sure: Please do not proceed with this before issue
> > > and PR templates are in place, labels are unified etc - meaning:
> > > GitHub repos are ready.
> > > (Working on this right now)
> > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron :
> > > >
> > > > I've done this for our JIRA:
> > > > - I've changed "Resolved" issues to "Closed" (about 8000+ of them)
> > > > - I've changed issues with "No Component" to the relevant component
> > > >
> > > > What's left:
> > > > - We have 1881 Open, Reopened or In Progress issues
> > > > - 474 were created in the last year (52 weeks)
> > > > - thus 1,407 were created more than a year ago
> > > > - 199 were created in the last 6 months (26 weeks)
> > > >
> > > > What's next:
> > > > 1. I can Bulk Resolve all issues with a comment so the reporters will
> > > > know where to re-file, with instructions, and point them to
> > > > issues.cordova.io [FAST]
> > > > OR
> > > > 2. I can Bulk Resolve issues by component, and point them to the right
> > > > GH repo to file the new issue [SLOW]
> > > >
> > > > Since this is a bulk operation, if we still need to keep some issues
> > > > open in JIRA, we need to tag with a label so I can skip those.
> > > >
> > > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski 
> > wrote:
> > > > >
> > > > > > 1. Should we just disable those then? One other way is to add in
> > bold
> > > > > > big letters about the deprecation in the New Issue template
> > > > >
> > > > > We should probably "just" define our deprecation and archival policy
> > > > > (see other active thread). Depending on that, we can create another
> > > > > INFRA issue to get taken care of that. There is no flood of Github
> > > > > issues for these repos right now, so no harm done.
> > > > >
> > > > > > 2. These links are super useful. Perhaps they should be on the
> > > > > > website, what do you all think? Not sure if the scripting for the
> > > > > > second link is server side or it could be client side as well (via
> > > > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/
> > > > > > (contribute.cordova.io) page. That massive github link could also
> > be
> > > > > > auto-generated as well on that page, somehow. Let me know how I can
> > > > > > help.
> > > > >
> > > > > Yes, I think those could very well be on the Cordova web site as
> > well.
> > > > > http://cordova.betamo.de/ is built with PHP, I will put its source
> > up
> > > > > on Github later so someone can rebuild it with JS if needed/wanted.
> &g

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Shazron]

Thanks Jan - I will hold off until we are ready of course.

Raphael - close as in there can not be any more comments added or
additions to the issue, not deletion. They will still exist and be
searchable. We definitely can add a label when we close them.
On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski  wrote:
>
> Just a note to make sure: Please do not proceed with this before issue
> and PR templates are in place, labels are unified etc - meaning:
> GitHub repos are ready.
> (Working on this right now)
> Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron :
> >
> > I've done this for our JIRA:
> > - I've changed "Resolved" issues to "Closed" (about 8000+ of them)
> > - I've changed issues with "No Component" to the relevant component
> >
> > What's left:
> > - We have 1881 Open, Reopened or In Progress issues
> > - 474 were created in the last year (52 weeks)
> > - thus 1,407 were created more than a year ago
> > - 199 were created in the last 6 months (26 weeks)
> >
> > What's next:
> > 1. I can Bulk Resolve all issues with a comment so the reporters will
> > know where to re-file, with instructions, and point them to
> > issues.cordova.io [FAST]
> > OR
> > 2. I can Bulk Resolve issues by component, and point them to the right
> > GH repo to file the new issue [SLOW]
> >
> > Since this is a bulk operation, if we still need to keep some issues
> > open in JIRA, we need to tag with a label so I can skip those.
> >
> > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski  wrote:
> > >
> > > > 1. Should we just disable those then? One other way is to add in bold
> > > > big letters about the deprecation in the New Issue template
> > >
> > > We should probably "just" define our deprecation and archival policy
> > > (see other active thread). Depending on that, we can create another
> > > INFRA issue to get taken care of that. There is no flood of Github
> > > issues for these repos right now, so no harm done.
> > >
> > > > 2. These links are super useful. Perhaps they should be on the
> > > > website, what do you all think? Not sure if the scripting for the
> > > > second link is server side or it could be client side as well (via
> > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/
> > > > (contribute.cordova.io) page. That massive github link could also be
> > > > auto-generated as well on that page, somehow. Let me know how I can
> > > > help.
> > >
> > > Yes, I think those could very well be on the Cordova web site as well.
> > > http://cordova.betamo.de/ is built with PHP, I will put its source up
> > > on Github later so someone can rebuild it with JS if needed/wanted.
> > > For now it is just a solution for us committers (and especially
> > > myself).
> > >
> > > -J
> > >
> > > 2018-08-08 5:34 GMT+02:00 Shazron :
> > > > Thanks Jan!
> > > >
> > > > 1. Should we just disable those then? One other way is to add in bold
> > > > big letters about the deprecation in the New Issue template
> > > > 2. These links are super useful. Perhaps they should be on the
> > > > website, what do you all think? Not sure if the scripting for the
> > > > second link is server side or it could be client side as well (via
> > > > JavaScript). Perhaps on the https://cordova.apache.org/contribute/
> > > > (contribute.cordova.io) page. That massive github link could also be
> > > > auto-generated as well on that page, somehow. Let me know how I can
> > > > help.
> > > > On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski  
> > > > wrote:
> > > >>
> > > >> You may have noticed the first issues coming in on some repositories.
> > > >>
> > > >> 1. In hindsight enabling issues for deprecated platforms, plugins etc
> > > >> may not have been the smartest decision. We will have to find out how
> > > >> to handle this - we should probably write down a "deprecation /
> > > >> archivation policy" anyway.
> > > >>
> > > >> 2. Some people are missing the "all tickets in one view" interface. I
> > > >> quickly built http://cordova.betamo.de/ as a workaround.
> > > >> The second link on there generates a few prepared Github search links,
> > > >> including one that is valid for _all_ Cordova repositories:
> > >

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Shazron]

I've done this for our JIRA:
- I've changed "Resolved" issues to "Closed" (about 8000+ of them)
- I've changed issues with "No Component" to the relevant component

What's left:
- We have 1881 Open, Reopened or In Progress issues
- 474 were created in the last year (52 weeks)
- thus 1,407 were created more than a year ago
- 199 were created in the last 6 months (26 weeks)

What's next:
1. I can Bulk Resolve all issues with a comment so the reporters will
know where to re-file, with instructions, and point them to
issues.cordova.io [FAST]
OR
2. I can Bulk Resolve issues by component, and point them to the right
GH repo to file the new issue [SLOW]

Since this is a bulk operation, if we still need to keep some issues
open in JIRA, we need to tag with a label so I can skip those.

On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski  wrote:
>
> > 1. Should we just disable those then? One other way is to add in bold
> > big letters about the deprecation in the New Issue template
>
> We should probably "just" define our deprecation and archival policy
> (see other active thread). Depending on that, we can create another
> INFRA issue to get taken care of that. There is no flood of Github
> issues for these repos right now, so no harm done.
>
> > 2. These links are super useful. Perhaps they should be on the
> > website, what do you all think? Not sure if the scripting for the
> > second link is server side or it could be client side as well (via
> > JavaScript). Perhaps on the https://cordova.apache.org/contribute/
> > (contribute.cordova.io) page. That massive github link could also be
> > auto-generated as well on that page, somehow. Let me know how I can
> > help.
>
> Yes, I think those could very well be on the Cordova web site as well.
> http://cordova.betamo.de/ is built with PHP, I will put its source up
> on Github later so someone can rebuild it with JS if needed/wanted.
> For now it is just a solution for us committers (and especially
> myself).
>
> -J
>
> 2018-08-08 5:34 GMT+02:00 Shazron :
> > Thanks Jan!
> >
> > 1. Should we just disable those then? One other way is to add in bold
> > big letters about the deprecation in the New Issue template
> > 2. These links are super useful. Perhaps they should be on the
> > website, what do you all think? Not sure if the scripting for the
> > second link is server side or it could be client side as well (via
> > JavaScript). Perhaps on the https://cordova.apache.org/contribute/
> > (contribute.cordova.io) page. That massive github link could also be
> > auto-generated as well on that page, somehow. Let me know how I can
> > help.
> > On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski  wrote:
> >>
> >> You may have noticed the first issues coming in on some repositories.
> >>
> >> 1. In hindsight enabling issues for deprecated platforms, plugins etc
> >> may not have been the smartest decision. We will have to find out how
> >> to handle this - we should probably write down a "deprecation /
> >> archivation policy" anyway.
> >>
> >> 2. Some people are missing the "all tickets in one view" interface. I
> >> quickly built http://cordova.betamo.de/ as a workaround.
> >> The second link on there generates a few prepared Github search links,
> >> including one that is valid for _all_ Cordova repositories:
> >> https://github.com/issues?q=type%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins

Re: What to do with cordova-discuss?

[Shazron]

It's mainly about discoverability, now that we have `cordova` repo
itself (one stop shop for general issues?). `discuss` repo was there
as you mentioned for historical reasons. Now that we have the
`cordova` repo, and we can discuss in the Issues of that repo, another
repo for discussion is redundant IMO. We could move issues from one
repo to another, if need be (not sure how, without some bot like
Probot)

In any case if we don't want to move that is fine as well, since all
PRs and Issues are reflected in the commits@ mailing list (which is
the most important record-keeping thing for Apache).

On Thu, Aug 23, 2018 at 3:52 PM Jan Piotrowski  wrote:
>
> Wasn't `cordova-discuss` for a totally different use case?
>
> From how I understood it, Cordova has/had a formal "proposal" process
> that consisted of someone writing a proposal as a PR for higher level
> topics. Then a discussion was triggered via an email to this list,
> which was had in the comments and reviews of the PR. Text was adapted
> and changed, later the proposal was voted on on the list again. If it
> was accepted, the proposal was merged into the repository and progress
> was kept track via changes to the document again. Correct?
>
> If this process should be abolished, fine.
> If not, it should be documented so knowledge about it isn't just anecdotal.
> But moving it over to apache/cordova doesn't make sense.
>
> What organically happened in the issues of cordova-discuss - it kind
> of became a place for issues without a proposal as well - was just
> because it was one of the only Cordova repositories with issues
> enabled (as it used to live in the `cordova` organisation, not
> "apache", on Github) before.
> Now most of the issues there can just be moved to the correct
> component repository. If an "overview" of those is needed, we got the
> GitHub Apache Cordova project board that could probably be used for
> that (keep track of issues across multiple repositories and even
> categorize them).
>
> If there are issues left after that, those could be placed into
> `apache/cordova` as a "high level cordova discussion" area if we
> define it that way.
>
> J
>
>
> Am Do., 23. Aug. 2018 um 08:01 Uhr schrieb Shazron :
> >
> > I think we should stick to one repo --
> > https://github.com/apache/cordova and archive the discuss repo.
> > We should point to that one repo for all things Cordova w.r.t to dev.
> > On Thu, Aug 23, 2018 at 4:13 AM Chris Brody  wrote:
> > >
> > > While I personally think it would continue to fill an existing gap (track
> > > discussion of some random and otherwise uncategorized Cordova topics) it
> > > has proven to be unpopular.
> > >
> > > Some alternatives I can think of:
> > > * discuss such discussions in https://github.com/apache/cordova
> > > * discuss elsewhere such as cordova-coho or cordova-contribute
> > > * consider using a solution such as Discourse
> > >
> > > I am a bit concerned that discussions by email and in Slack are easy to
> > > forget and not easy to keep track of.
> > >
> > > P.S. As a side point I am not so happy to see most dev discussions on 
> > > Slack
> > > in private PMC channel. I would be much happier to see such discussions in
> > > a public channel such as "dev".
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: INFRA requests based on the F2F meeting

[Shazron]

Sorry hit send too quick.
I added jira.cordova.io as a transition step for us that points to the
current JIRA
On Thu, Aug 23, 2018 at 2:04 PM Shazron  wrote:
>
> I've changed the redirect issues.cordova.io to point to
> https://github.com/apache/cordova and added a pointer in the README on
> where to file an issue. It might take some time to propagate
> On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski  wrote:
> >
> > Oh wow, you already can't create issues for Cordova in JIRA any more.
> > That was quick.
> >
> > Is there maybe a way to somehow point people into the right direction in 
> > JIRA?
> > We will now of course update issues.cordova.io, but I assume some
> > peole have https://issues.apache.org/jira/projects/CB/ or similar URLs
> > bookmarked.
> >
> > -J
> >
> > 2018-08-16 10:34 GMT+02:00 Shazron :
> > > 1. Org Level Project Board 
> > > https://issues.apache.org/jira/browse/INFRA-16913
> > > 2. Lock down JIRA for creation of new issues
> > > https://issues.apache.org/jira/browse/INFRA-16914
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >

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

Re: INFRA requests based on the F2F meeting

[Shazron]

I've changed the redirect issues.cordova.io to point to
https://github.com/apache/cordova and added a pointer in the README on
where to file an issue. It might take some time to propagate
On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski  wrote:
>
> Oh wow, you already can't create issues for Cordova in JIRA any more.
> That was quick.
>
> Is there maybe a way to somehow point people into the right direction in JIRA?
> We will now of course update issues.cordova.io, but I assume some
> peole have https://issues.apache.org/jira/projects/CB/ or similar URLs
> bookmarked.
>
> -J
>
> 2018-08-16 10:34 GMT+02:00 Shazron :
> > 1. Org Level Project Board https://issues.apache.org/jira/browse/INFRA-16913
> > 2. Lock down JIRA for creation of new issues
> > https://issues.apache.org/jira/browse/INFRA-16914
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: What to do with cordova-discuss?

[Shazron]

I think we should stick to one repo --
https://github.com/apache/cordova and archive the discuss repo.
We should point to that one repo for all things Cordova w.r.t to dev.
On Thu, Aug 23, 2018 at 4:13 AM Chris Brody  wrote:
>
> While I personally think it would continue to fill an existing gap (track
> discussion of some random and otherwise uncategorized Cordova topics) it
> has proven to be unpopular.
>
> Some alternatives I can think of:
> * discuss such discussions in https://github.com/apache/cordova
> * discuss elsewhere such as cordova-coho or cordova-contribute
> * consider using a solution such as Discourse
>
> I am a bit concerned that discussions by email and in Slack are easy to
> forget and not easy to keep track of.
>
> P.S. As a side point I am not so happy to see most dev discussions on Slack
> in private PMC channel. I would be much happier to see such discussions in
> a public channel such as "dev".

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

Re: [DISCUSS] [Github Issues] Issue and Pull Request labels

[Shazron]

I would assume since we (committers) can create a New Label in Github,
we would have the permission to do so via API...
On Wed, Aug 22, 2018 at 2:28 AM  wrote:
>
> Labels that I would like to have:
>
> - something to show that you are open to suggestions or want to work out
> how something is supposed to work. Could be "discussion"
> - A "Work in Progress" label
>
> I would have tried to just write a script that creates the labels via GH
> API. But do we have the necessary permissions to do so?
>
> Jan Piotrowski  schrieb am Do., 9. Aug. 2018, 23:07:
>
> > Now that we have Github issues enabled for all our repositories,
> > another new thing we have to talk about are Github Issue and Pull
> > Request labels.
> >
> >
> > If you are not aware of Github labels, here is a nice introduction:
> > https://help.github.com/articles/about-labels/
> >
> > This also contains a list of the default labels all our repositories
> > got when issues were enabled:
> >
> > > bug, duplicate, good first issue, help wanted, invalid, question, wontfix
> >
> > https://help.github.com/articles/about-labels/#using-default-labels
> >
> > Issues also have a color, which - when chosen well and used uniform
> > across repositories - make it easier to scan the issue list.
> >
> >
> > As we come from JIRA, it's important to understand the differences.
> > A JIRA ticket has many different fields: Type, Status, Priority,
> > Resolution, Affects Version/s, Fix Version/s, Component/s, Labels,
> > Security Level, Environment, Estimate, Flag, External issue URL,
> > External issue ID, Epic Link, Sprint, Docs Text
> > On Github none of those exist. Most of this information has to be
> > supplied via the description of the issue (and can be requested via
> > the issue or PR template, see previous email), but it can also make
> > sense to map some of those via Github labels.
> >
> >
> > With the first few issues that came in on our repositories, I already
> > created the following two new labels:
> >
> > - `support` - Used for support questions that don't report a bug and
> > don't request a new feature but e.g. want to understand how something
> > works, need help debugging their individual problem etc. (This will
> > probably be the majority of the issue we are getting.)
> > - `platform: android` (ios, browser, windows, osx) - For plugin
> > repositories it makes sense to categorize e.g. a bug report or feature
> > request for its platform
> >
> >
> > Other projects have very structured labels:
> > https://github.com/fastlane/fastlane/labels
> > https://github.com/ionic-team/ionic-cli/labels
> >
> > Or pretty extensive lists of stuff:
> > https://github.com/Microsoft/TypeScript/labels
> > https://github.com/Microsoft/vscode/labels
> >
> > What do we actually need for the beginning?
> > Any other input?
> >
> >
> > Does anyone have an idea how we can "manage" our labels across our ~70
> > repositories? Are there any scripts out there that can automate the
> > creation/deletion of them via the Github API?
> >
> >
> > Best,
> > Jan
> >
> > -
> > 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: INFRA requests based on the F2F meeting

[Shazron]

Forgot to paste the link:
https://github.com/orgs/apache/projects/2

To grab issues from repos, Add Cards -> uncheck "Only show results
from linked repositories" then use a query to limit your search
On Wed, Aug 22, 2018 at 9:37 AM Shazron  wrote:
>
> The Org Project Level Board has been created. We can add issues from
> all repos in the Apache org now.
> https://issues.apache.org/jira/browse/INFRA-16913
>
>
> On Sat, Aug 18, 2018 at 4:22 PM Shazron  wrote:
> >
> > Update: INFRA has fixed the issue. We can make modifications on issues
> > again. Creation of issues is disabled -- only CB Project Admins can
> > create new issues.
> > On Sat, Aug 18, 2018 at 4:02 PM Shazron  wrote:
> > >
> > > I'll ask INFRA to revert the change.
> > > On Fri, Aug 17, 2018 at 3:51 PM Jan Piotrowski  
> > > wrote:
> > > >
> > > > Can confirm, Cordova JIRA seems to be fully read only now. Seems we
> > > > should roll back and only deactivate after we migrated everything
> > > > (somehow).
> > > >
> > > > 2018-08-17 5:05 GMT+02:00 Shazron :
> > > > > There might be a side effect on locking down JIRA. I can't comment on
> > > > > existing JIRA issues now.
> > > > > On Thu, Aug 16, 2018 at 9:40 PM Shazron  wrote:
> > > > >>
> > > > >> Not sure how, maybe edit some project settings in JIRA, need to 
> > > > >> investigate.
> > > > >>
> > > > >> On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski 
> > > > >>  wrote:
> > > > >>>
> > > > >>> Oh wow, you already can't create issues for Cordova in JIRA any 
> > > > >>> more.
> > > > >>> That was quick.
> > > > >>>
> > > > >>> Is there maybe a way to somehow point people into the right 
> > > > >>> direction in JIRA?
> > > > >>> We will now of course update issues.cordova.io, but I assume some
> > > > >>> peole have https://issues.apache.org/jira/projects/CB/ or similar 
> > > > >>> URLs
> > > > >>> bookmarked.
> > > > >>>
> > > > >>> -J
> > > > >>>
> > > > >>> 2018-08-16 10:34 GMT+02:00 Shazron :
> > > > >>> > 1. Org Level Project Board 
> > > > >>> > https://issues.apache.org/jira/browse/INFRA-16913
> > > > >>> > 2. Lock down JIRA for creation of new issues
> > > > >>> > https://issues.apache.org/jira/browse/INFRA-16914
> > > > >>> >
> > > > >>> > -
> > > > >>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > >>> > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > > >>> >
> > > > >>>
> > > > >>> -
> > > > >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > >>> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > > >>>
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >

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

Re: INFRA requests based on the F2F meeting

[Shazron]

The Org Project Level Board has been created. We can add issues from
all repos in the Apache org now.
https://issues.apache.org/jira/browse/INFRA-16913


On Sat, Aug 18, 2018 at 4:22 PM Shazron  wrote:
>
> Update: INFRA has fixed the issue. We can make modifications on issues
> again. Creation of issues is disabled -- only CB Project Admins can
> create new issues.
> On Sat, Aug 18, 2018 at 4:02 PM Shazron  wrote:
> >
> > I'll ask INFRA to revert the change.
> > On Fri, Aug 17, 2018 at 3:51 PM Jan Piotrowski  wrote:
> > >
> > > Can confirm, Cordova JIRA seems to be fully read only now. Seems we
> > > should roll back and only deactivate after we migrated everything
> > > (somehow).
> > >
> > > 2018-08-17 5:05 GMT+02:00 Shazron :
> > > > There might be a side effect on locking down JIRA. I can't comment on
> > > > existing JIRA issues now.
> > > > On Thu, Aug 16, 2018 at 9:40 PM Shazron  wrote:
> > > >>
> > > >> Not sure how, maybe edit some project settings in JIRA, need to 
> > > >> investigate.
> > > >>
> > > >> On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski  
> > > >> wrote:
> > > >>>
> > > >>> Oh wow, you already can't create issues for Cordova in JIRA any more.
> > > >>> That was quick.
> > > >>>
> > > >>> Is there maybe a way to somehow point people into the right direction 
> > > >>> in JIRA?
> > > >>> We will now of course update issues.cordova.io, but I assume some
> > > >>> peole have https://issues.apache.org/jira/projects/CB/ or similar URLs
> > > >>> bookmarked.
> > > >>>
> > > >>> -J
> > > >>>
> > > >>> 2018-08-16 10:34 GMT+02:00 Shazron :
> > > >>> > 1. Org Level Project Board 
> > > >>> > https://issues.apache.org/jira/browse/INFRA-16913
> > > >>> > 2. Lock down JIRA for creation of new issues
> > > >>> > https://issues.apache.org/jira/browse/INFRA-16914
> > > >>> >
> > > >>> > -
> > > >>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > >>> > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >>> >
> > > >>>
> > > >>> -
> > > >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > >>> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >>>
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >

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

Re: Documentation and plugin search is not working

[Shazron]

Doc search is back up, thanks to Algolia for finding the issue!
There are some recommendations for us to update our docs to minimize
disruption with changes, I will update the JIRA issue -- I probably
will migrate it to a Github Issue first and link it.
On Tue, Aug 14, 2018 at 11:56 AM Shazron  wrote:
>
> Doc search issue:
> https://issues.apache.org/jira/browse/CB-14266
>
> Plugin search issue:
> https://issues.apache.org/jira/browse/CB-14265

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

Re: INFRA requests based on the F2F meeting

[Shazron]

Update: INFRA has fixed the issue. We can make modifications on issues
again. Creation of issues is disabled -- only CB Project Admins can
create new issues.
On Sat, Aug 18, 2018 at 4:02 PM Shazron  wrote:
>
> I'll ask INFRA to revert the change.
> On Fri, Aug 17, 2018 at 3:51 PM Jan Piotrowski  wrote:
> >
> > Can confirm, Cordova JIRA seems to be fully read only now. Seems we
> > should roll back and only deactivate after we migrated everything
> > (somehow).
> >
> > 2018-08-17 5:05 GMT+02:00 Shazron :
> > > There might be a side effect on locking down JIRA. I can't comment on
> > > existing JIRA issues now.
> > > On Thu, Aug 16, 2018 at 9:40 PM Shazron  wrote:
> > >>
> > >> Not sure how, maybe edit some project settings in JIRA, need to 
> > >> investigate.
> > >>
> > >> On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski  
> > >> wrote:
> > >>>
> > >>> Oh wow, you already can't create issues for Cordova in JIRA any more.
> > >>> That was quick.
> > >>>
> > >>> Is there maybe a way to somehow point people into the right direction 
> > >>> in JIRA?
> > >>> We will now of course update issues.cordova.io, but I assume some
> > >>> peole have https://issues.apache.org/jira/projects/CB/ or similar URLs
> > >>> bookmarked.
> > >>>
> > >>> -J
> > >>>
> > >>> 2018-08-16 10:34 GMT+02:00 Shazron :
> > >>> > 1. Org Level Project Board 
> > >>> > https://issues.apache.org/jira/browse/INFRA-16913
> > >>> > 2. Lock down JIRA for creation of new issues
> > >>> > https://issues.apache.org/jira/browse/INFRA-16914
> > >>> >
> > >>> > -
> > >>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >>> > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>> >
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >>> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >

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

Re: INFRA requests based on the F2F meeting

[Shazron]

I'll ask INFRA to revert the change.
On Fri, Aug 17, 2018 at 3:51 PM Jan Piotrowski  wrote:
>
> Can confirm, Cordova JIRA seems to be fully read only now. Seems we
> should roll back and only deactivate after we migrated everything
> (somehow).
>
> 2018-08-17 5:05 GMT+02:00 Shazron :
> > There might be a side effect on locking down JIRA. I can't comment on
> > existing JIRA issues now.
> > On Thu, Aug 16, 2018 at 9:40 PM Shazron  wrote:
> >>
> >> Not sure how, maybe edit some project settings in JIRA, need to 
> >> investigate.
> >>
> >> On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski  
> >> wrote:
> >>>
> >>> Oh wow, you already can't create issues for Cordova in JIRA any more.
> >>> That was quick.
> >>>
> >>> Is there maybe a way to somehow point people into the right direction in 
> >>> JIRA?
> >>> We will now of course update issues.cordova.io, but I assume some
> >>> peole have https://issues.apache.org/jira/projects/CB/ or similar URLs
> >>> bookmarked.
> >>>
> >>> -J
> >>>
> >>> 2018-08-16 10:34 GMT+02:00 Shazron :
> >>> > 1. Org Level Project Board 
> >>> > https://issues.apache.org/jira/browse/INFRA-16913
> >>> > 2. Lock down JIRA for creation of new issues
> >>> > https://issues.apache.org/jira/browse/INFRA-16914
> >>> >
> >>> > -
> >>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >>> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >>> >
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >>> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: INFRA requests based on the F2F meeting

[Shazron]

There might be a side effect on locking down JIRA. I can't comment on
existing JIRA issues now.
On Thu, Aug 16, 2018 at 9:40 PM Shazron  wrote:
>
> Not sure how, maybe edit some project settings in JIRA, need to investigate.
>
> On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski  wrote:
>>
>> Oh wow, you already can't create issues for Cordova in JIRA any more.
>> That was quick.
>>
>> Is there maybe a way to somehow point people into the right direction in 
>> JIRA?
>> We will now of course update issues.cordova.io, but I assume some
>> peole have https://issues.apache.org/jira/projects/CB/ or similar URLs
>> bookmarked.
>>
>> -J
>>
>> 2018-08-16 10:34 GMT+02:00 Shazron :
>> > 1. Org Level Project Board 
>> > https://issues.apache.org/jira/browse/INFRA-16913
>> > 2. Lock down JIRA for creation of new issues
>> > https://issues.apache.org/jira/browse/INFRA-16914
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>

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

Re: INFRA requests based on the F2F meeting

[Shazron]

Not sure how, maybe edit some project settings in JIRA, need to investigate.

On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski  wrote:

> Oh wow, you already can't create issues for Cordova in JIRA any more.
> That was quick.
>
> Is there maybe a way to somehow point people into the right direction in
> JIRA?
> We will now of course update issues.cordova.io, but I assume some
> peole have https://issues.apache.org/jira/projects/CB/ or similar URLs
> bookmarked.
>
> -J
>
> 2018-08-16 10:34 GMT+02:00 Shazron :
> > 1. Org Level Project Board
> https://issues.apache.org/jira/browse/INFRA-16913
> > 2. Lock down JIRA for creation of new issues
> > https://issues.apache.org/jira/browse/INFRA-16914
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS cordova-windows@6.0.1 patch release

[Shazron]

I'm still investigating this splashscreen issue -- not sure if
something broke, or I haven't defined something
(am n00b on Windows platform...)
On Wed, Aug 15, 2018 at 4:19 PM Jan Piotrowski  wrote:
>
> > I had to set the MSBUILDDIR env var explicitly to C:\Program Files
> > (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin since
> > our code fails to detect the MSBuild version installed with that,
> > v15.8.
> >
> > The registry entry it checks still has MSBuild v4 from the .NET
> > Framework -- so perhaps our detection is outdated.
>
> From what I remember our MSBuild detection logic is a bit more
> complicated and does many, many things to find it.
> My best guess here is that somewhere `15.8` would have to be added to
> a list - when cordova-windows 6.0.0 was released the correct MSBuild
> was autodetected.
> Should probably be rewritten completely :/
>
> > I had also noticed this issue, with Visual Studio 2017, from our AppVeyor 
> > tests.
> > The AppVeyor configuration is set to accept the failures as a passing 
> > result if using Visual Studio 2017.
> > I had been wanting to fix this so the tests would actually run and pass 
> > properly but didn’t have too much time to look into this.
>
> AppVeyor fails for Visual Studio 2017 because of one unexplained test
> failure, that only happens on CI.
> (I thought there already was an issue, seems I was wrong. Created
> https://github.com/apache/cordova-windows/issues/290).
>
> J
>
> 2018-08-15 8:16 GMT+02:00 Bryan Ellis :
> > I had also noticed this issue, with Visual Studio 2017, from our AppVeyor 
> > tests.
> >
> > https://ci.appveyor.com/project/Humbedooh/cordova-windows/build/1.0.1020
> >
> > The AppVeyor configuration is set to accept the failures as a passing 
> > result if using Visual Studio 2017.
> >
> > I had been wanting to fix this so the tests would actually run and pass 
> > properly but didn’t have too much time to look into this.
> >
> >
> >> On Aug 15, 2018, at 14:54, Shazron  wrote:
> >>
> >> https://github.com/apache/cordova-windows/issues/274 which is not a
> >> blocker IMO, but I'm not sure of the splash screen. Technically the
> >> app builds and runs...
> >> On Wed, Aug 15, 2018 at 1:40 PM Shazron  wrote:
> >>>
> >>> You can debug what requirements it tries to detect for MSBUILD by running:
> >>>cordova requirements --verbose
> >>> On Wed, Aug 15, 2018 at 1:39 PM Shazron  wrote:
> >>>>
> >>>> Repro steps:
> >>>>
> >>>> ```
> >>>> npm install -g cordova
> >>>> cordova create foo
> >>>> cd foo
> >>>> cordova platform add https://github.com/apache/cordova-windows#6.0.1
> >>>> cordova run
> >>>> ```
> >>>>
> >>>> Pre-requisites:
> >>>> - Visual Studio 2017 Community installed with defaults
> >>>> - Windows 10 SDK
> >>>> - Set env var `MSBUILDDIR` to 'C:\Program Files
> >>>> (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin'
> >>>>
> >>>> On Wed, Aug 15, 2018 at 1:36 PM Shazron  wrote:
> >>>>>
> >>>>> Had trouble meeting the requirements to build, using VS 2017 Community 
> >>>>> edition
> >>>>> I had to set the MSBUILDDIR env var explicitly to C:\Program Files
> >>>>> (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin since
> >>>>> our code fails to detect the MSBuild version installed with that,
> >>>>> v15.8.
> >>>>>
> >>>>> The registry entry it checks still has MSBuild v4 from the .NET
> >>>>> Framework -- so perhaps our detection is outdated.
> >>>>>
> >>>>> After I added the env var, I could `cordova build`.
> >>>>> `cordova run` guided me to change some settings and run in elevated
> >>>>> permissions, and I ran `cordova run` again.
> >>>>>
> >>>>> The app launches, and I get a 'broken image` icon for the splash
> >>>>> screen. Is this a known issue?
> >>
> >> -
> >> 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

INFRA requests based on the F2F meeting

[Shazron]

1. Org Level Project Board https://issues.apache.org/jira/browse/INFRA-16913
2. Lock down JIRA for creation of new issues
https://issues.apache.org/jira/browse/INFRA-16914

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

Re: [DISCUSS cordova-windows@6.0.1 patch release

[Shazron]

https://github.com/apache/cordova-windows/issues/274 which is not a
blocker IMO, but I'm not sure of the splash screen. Technically the
app builds and runs...
On Wed, Aug 15, 2018 at 1:40 PM Shazron  wrote:
>
> You can debug what requirements it tries to detect for MSBUILD by running:
> cordova requirements --verbose
> On Wed, Aug 15, 2018 at 1:39 PM Shazron  wrote:
> >
> > Repro steps:
> >
> > ```
> > npm install -g cordova
> > cordova create foo
> > cd foo
> > cordova platform add https://github.com/apache/cordova-windows#6.0.1
> > cordova run
> > ```
> >
> > Pre-requisites:
> > - Visual Studio 2017 Community installed with defaults
> > - Windows 10 SDK
> > - Set env var `MSBUILDDIR` to 'C:\Program Files
> > (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin'
> >
> > On Wed, Aug 15, 2018 at 1:36 PM Shazron  wrote:
> > >
> > > Had trouble meeting the requirements to build, using VS 2017 Community 
> > > edition
> > > I had to set the MSBUILDDIR env var explicitly to C:\Program Files
> > > (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin since
> > > our code fails to detect the MSBuild version installed with that,
> > > v15.8.
> > >
> > > The registry entry it checks still has MSBuild v4 from the .NET
> > > Framework -- so perhaps our detection is outdated.
> > >
> > > After I added the env var, I could `cordova build`.
> > > `cordova run` guided me to change some settings and run in elevated
> > > permissions, and I ran `cordova run` again.
> > >
> > > The app launches, and I get a 'broken image` icon for the splash
> > > screen. Is this a known issue?

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

Re: [DISCUSS cordova-windows@6.0.1 patch release

[Shazron]

You can debug what requirements it tries to detect for MSBUILD by running:
cordova requirements --verbose
On Wed, Aug 15, 2018 at 1:39 PM Shazron  wrote:
>
> Repro steps:
>
> ```
> npm install -g cordova
> cordova create foo
> cd foo
> cordova platform add https://github.com/apache/cordova-windows#6.0.1
> cordova run
> ```
>
> Pre-requisites:
> - Visual Studio 2017 Community installed with defaults
> - Windows 10 SDK
> - Set env var `MSBUILDDIR` to 'C:\Program Files
> (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin'
>
> On Wed, Aug 15, 2018 at 1:36 PM Shazron  wrote:
> >
> > Had trouble meeting the requirements to build, using VS 2017 Community 
> > edition
> > I had to set the MSBUILDDIR env var explicitly to C:\Program Files
> > (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin since
> > our code fails to detect the MSBuild version installed with that,
> > v15.8.
> >
> > The registry entry it checks still has MSBuild v4 from the .NET
> > Framework -- so perhaps our detection is outdated.
> >
> > After I added the env var, I could `cordova build`.
> > `cordova run` guided me to change some settings and run in elevated
> > permissions, and I ran `cordova run` again.
> >
> > The app launches, and I get a 'broken image` icon for the splash
> > screen. Is this a known issue?

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

[DISCUSS cordova-windows@6.0.1 patch release

[Shazron]

Had trouble meeting the requirements to build, using VS 2017 Community edition
I had to set the MSBUILDDIR env var explicitly to C:\Program Files
(x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin since
our code fails to detect the MSBuild version installed with that,
v15.8.

The registry entry it checks still has MSBuild v4 from the .NET
Framework -- so perhaps our detection is outdated.

After I added the env var, I could `cordova build`.
`cordova run` guided me to change some settings and run in elevated
permissions, and I ran `cordova run` again.

The app launches, and I get a 'broken image` icon for the splash
screen. Is this a known issue?

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

Documentation and plugin search is not working

[Shazron]

Doc search issue:
https://issues.apache.org/jira/browse/CB-14266

Plugin search issue:
https://issues.apache.org/jira/browse/CB-14265

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

Re: Reviving Face-to-Face video meetings?

[Shazron]

Thanks Darryl! I'll try to make this one...
On Sat, Aug 11, 2018 at 11:12 AM Darryl Pogue  wrote:
>
> Okay, it looks like the date that works best for everyone is Wednesday:
>
> Wednesday, August 15th, 2018 at 15:00 - 17:00 UTC
>
> For that event in your local timezone, please consult
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Cordova+Video+Meeting=20180815T15=1440=2
>
> In the past we've used Google Hangouts on Air so that non-participants
> are able to watch the meeting on YouTube and it's recorded for later.
> I'll try to figure out what's involved in setting that up, and we can
> fallback to something like Skype or Zoom if need be.
>
> I'll also try to put together a rough agenda Google Doc for review on Monday.
>
> Thanks,
> ~Darryl
>
>
> On Thu, Aug 9, 2018 at 2:21 AM Chris Brody  wrote:
> >
> > Looking forward to the final result (hope you send by email), thanks!
> > On Thu, Aug 9, 2018 at 2:32 AM Darryl Pogue  wrote:
> > >
> > > Yes! Sorry for missing my intended deadline here, some unexpected work
> > > challenges combined with moving house and not having my full computer
> > > set up yet have caused me to drop a few things, including following up
> > > on scheduling this.
> > >
> > > I've set up a Doodle poll with dates for next week, let's try to have
> > > a date picked by this coming Friday (August 10th).
> > >
> > > *** TIMES ARE IN UTC. PLEASE CHECK CONVERSION TO YOUR LOCAL TIME
> > > BEFORE REPLYING. ***
> > > https://doodle.com/poll/c6nhksdmv2tgd8rf
> > >
> > > I'm hoping we can find something that can work not only for North
> > > Americans, but also for our European contributors as well as our
> > > Japanese ones. However, given that those are roughly equally spaced
> > > around the globe, somebody is probably going to be stuck with
> > > something outside of ideal hours. You can click twice in the checkbox
> > > to mark it as "possible, but not ideal".
> > >
> > > ~Darryl
> > >
> > > On Wed, Aug 8, 2018 at 7:14 PM Bryan Ellis  wrote:
> > > >
> > > > Hi Darryl,
> > > >
> > > > I see it had past Aug 3rd and I wanted to find out if we are still 
> > > > planning to set up a web conference.
> > > >
> > > > I am looking forward to the web conference. Please let me know if there 
> > > > is anything I can do to help get this moving.
> > > >
> > > >
> > > > > On Jul 19, 2018, at 14:23, Shazron  wrote:
> > > > >
> > > > > +1!
> > > > > On Thu, Jul 19, 2018 at 1:17 PM Bryan Ellis  
> > > > > wrote:
> > > > >>
> > > > >> I also believe that this is a great idea and would be interested in
> > > > >> participating.
> > > > >>
> > > > >> Anytime between now and August 3rd will work for me.
> > > > >>
> > > > >> On Thu, Jul 19, 2018 at 10:50 AM Gearóid M  
> > > > >> wrote:
> > > > >>
> > > > >>> Great idea, I'd like to get to know the Cordova contributors. I 
> > > > >>> probably
> > > > >>> will not be available in the next few weeks, but I would like to 
> > > > >>> join in
> > > > >>> in the future if it becomes a regular occurrence.
> > > > >>>
> > > > >>> On 2018/07/18 3:59, raphine...@gmail.com wrote:
> > > > >>>> Definitely!
> > > > >>>>
> > > > >>>> Chris Brody  schrieb am Di., 17. Juli 2018,
> > > > >>> 20:30:
> > > > >>>>
> > > > >>>>> +1, would be really nice!
> > > > >>>>> On Tue, Jul 17, 2018 at 2:19 PM Darryl Pogue  
> > > > >>>>> wrote:
> > > > >>>>>> Hey folks,
> > > > >>>>>>
> > > > >>>>>> In the days of old, the Cordova project tried to have 
> > > > >>>>>> semi-regular
> > > > >>>>>> video conference meetings on Hangouts for coordinating work and
> > > > >>>>>> getting to know fellow collaborators a bit better. Those dropped 
> > > > >>>>>> off
> > > > >>>>>> as people became less active on the project, but with a bunch of 
> > > > >

Re: [VOTE] cordova-osx 4.0.2 patch release

[Shazron]

I vote +1
- I could add the platform
- I could run 'cordova build' and 'cordova run' successfully

On Mon, Jul 30, 2018 at 12:26 PM Chris Brody  wrote:
>
> Please review and vote on this 4.0.2 cordova-osx (macOS) patch release
> by replying to this email (and keep discussion on the DISCUSS thread).
>
> Release issue: https://issues.apache.org/jira/browse/CB-14228
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-14228/
>
> The package was published from its corresponding git tag:
>
> cordova-osx: 4.0.2 (8cda5fa8d8)
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-osx#4.0.2
>
> 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
> * tested with cordova-sqlite-storage plugin using npm@2.15.11
> (packaged with node@4.9.1) - more details in:
> https://github.com/apache/cordova-osx/pull/51
> * additional testing with details in:
> https://github.com/apache/cordova-osx/pull/50
>
> Proposed blog post in: https://github.com/apache/cordova-docs/pull/856
>
> -
> 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: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

Blog post up:
https://cordova.apache.org/news/2018/08/01/future-cordova-ios-webview.html

Retweet this:
https://twitter.com/apachecordova/status/1027397670430601216
On Thu, Aug 9, 2018 at 9:55 AM Shazron  wrote:
>
> Julio,
> Darryl mentioned " iframes being cross origin (so no accessing the
> parent/child document)" which means that it is a break from existing
> UIWebView behaviour that users expect, that will now break. There are
> workarounds: 
> https://medium.com/@DrawandCode/how-to-communicate-with-iframes-inside-webview-2c9c86436edb
> but this is not very cross-platform, nor something we want to
> encourage further. Like Jesse said, it happens to work with UIWebView
> -- not something we actively support.
>
> There is a software philosophy (probably some Microsoft camp) that
> says you shouldn't break users when you upgrade -- if users rely on a
> 'bug' for so long (in this case no CORS), it has now become a feature
> -- but that is if you control the platform. We however don't have
> control over WKWebView, so its not up to us. That is why I am
> reluctant to bake in features that workaround some of these security
> controls, and instead rely on external plugins (my personal opinion).
> It should be an active decision from the developer to override the
> controls of WKWebView if they so choose, and we will help with
> information on how to do so as a stopgap, not as the ultimate
> solution.
> On Wed, Aug 8, 2018 at 10:47 PM julio cesar sanchez
>  wrote:
> >
> > What's exactly the iframe problem?
> >
> > El mié., 8 ago. 2018 a las 10:05, Niklas Merz ()
> > escribió:
> >
> > > +1
> > >
> > > I am really happy to hear about the WKwebview future. I tried WKwebview
> > > some time ago and it did not work well with our app. I think the changes
> > > mentioned in the blog post will make the transition to WKwebview easier.
> > > Not supporting some features like iframes may be an issue for some users
> > > they should be aware of.
> > >
> > > Am 8. Aug. 2018, 09:30, um 09:30, Jesse  schrieb:
> > > >+1. Please post it.
> > > >
> > > >I think it is better to put it out there and get feedback from the
> > > >wider
> > > >community, than sit and try to perfect a message here with a subset of
> > > >subscribers.
> > > >We can only do the best we can with what we have.
> > > >
> > > >Regarding things like iframes, I am not sure they are worth keeping
> > > >around,
> > > >it seems like a bit of an anti-pattern and a better inappbrowser might
> > > >be a
> > > >better approach ... really what I mean is, we have focused so much on
> > > >making EVERYTHING-WEB work in cordova, but we may be coming to a time
> > > >where
> > > >we have to focus on just the features we need to build good hybrid
> > > >apps.
> > > >
> > > >We never promised anyone that iframes would work ... they just always
> > > >have.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >@purplecabbage
> > > >risingj.com
> > > >
> > > >On Wed, Aug 8, 2018 at 12:16 AM, Shazron  wrote:
> > > >
> > > >> If there are no further comments regarding the blog post, I will
> > > >> publish it by EOD (Pacific Time) Wed August 8th, 2018
> > > >> https://github.com/apache/cordova-docs/pull/867
> > > >> On Wed, Aug 8, 2018 at 3:14 PM Shazron  wrote:
> > > >> >
> > > >> > Apple has other goals with WKWebView (a lot deals with making it
> > > >more
> > > >> > secure), and I doubt they are aligned with Cordova's goals
> > > >(although
> > > >> > they did a patch to load file urls for iOS 9 I believe, that helped
> > > >us
> > > >> > avoid the local webserver route). I think almost all of us know
> > > >that
> > > >> > WKWebView usage by Cordova is an implementation with a lot of
> > > >> > patchwork, and definitely hacky, so that we can achieve feature
> > > >parity
> > > >> > with our usage of UIWebView.
> > > >> >
> > > >> > Ionic is always welcome to chime in and contribute to the blog
> > > >post,
> > > >> > and submit patches.
> > > >> >
> > > >> > Unfortunately Apple has made the choice for us. We have to move on
> > > >to
> 

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

Julio,
Darryl mentioned " iframes being cross origin (so no accessing the
parent/child document)" which means that it is a break from existing
UIWebView behaviour that users expect, that will now break. There are
workarounds: 
https://medium.com/@DrawandCode/how-to-communicate-with-iframes-inside-webview-2c9c86436edb
but this is not very cross-platform, nor something we want to
encourage further. Like Jesse said, it happens to work with UIWebView
-- not something we actively support.

There is a software philosophy (probably some Microsoft camp) that
says you shouldn't break users when you upgrade -- if users rely on a
'bug' for so long (in this case no CORS), it has now become a feature
-- but that is if you control the platform. We however don't have
control over WKWebView, so its not up to us. That is why I am
reluctant to bake in features that workaround some of these security
controls, and instead rely on external plugins (my personal opinion).
It should be an active decision from the developer to override the
controls of WKWebView if they so choose, and we will help with
information on how to do so as a stopgap, not as the ultimate
solution.
On Wed, Aug 8, 2018 at 10:47 PM julio cesar sanchez
 wrote:
>
> What's exactly the iframe problem?
>
> El mié., 8 ago. 2018 a las 10:05, Niklas Merz ()
> escribió:
>
> > +1
> >
> > I am really happy to hear about the WKwebview future. I tried WKwebview
> > some time ago and it did not work well with our app. I think the changes
> > mentioned in the blog post will make the transition to WKwebview easier.
> > Not supporting some features like iframes may be an issue for some users
> > they should be aware of.
> >
> > Am 8. Aug. 2018, 09:30, um 09:30, Jesse  schrieb:
> > >+1. Please post it.
> > >
> > >I think it is better to put it out there and get feedback from the
> > >wider
> > >community, than sit and try to perfect a message here with a subset of
> > >subscribers.
> > >We can only do the best we can with what we have.
> > >
> > >Regarding things like iframes, I am not sure they are worth keeping
> > >around,
> > >it seems like a bit of an anti-pattern and a better inappbrowser might
> > >be a
> > >better approach ... really what I mean is, we have focused so much on
> > >making EVERYTHING-WEB work in cordova, but we may be coming to a time
> > >where
> > >we have to focus on just the features we need to build good hybrid
> > >apps.
> > >
> > >We never promised anyone that iframes would work ... they just always
> > >have.
> > >
> > >
> > >
> > >
> > >
> > >@purplecabbage
> > >risingj.com
> > >
> > >On Wed, Aug 8, 2018 at 12:16 AM, Shazron  wrote:
> > >
> > >> If there are no further comments regarding the blog post, I will
> > >> publish it by EOD (Pacific Time) Wed August 8th, 2018
> > >> https://github.com/apache/cordova-docs/pull/867
> > >> On Wed, Aug 8, 2018 at 3:14 PM Shazron  wrote:
> > >> >
> > >> > Apple has other goals with WKWebView (a lot deals with making it
> > >more
> > >> > secure), and I doubt they are aligned with Cordova's goals
> > >(although
> > >> > they did a patch to load file urls for iOS 9 I believe, that helped
> > >us
> > >> > avoid the local webserver route). I think almost all of us know
> > >that
> > >> > WKWebView usage by Cordova is an implementation with a lot of
> > >> > patchwork, and definitely hacky, so that we can achieve feature
> > >parity
> > >> > with our usage of UIWebView.
> > >> >
> > >> > Ionic is always welcome to chime in and contribute to the blog
> > >post,
> > >> > and submit patches.
> > >> >
> > >> > Unfortunately Apple has made the choice for us. We have to move on
> > >to
> > >> > WKWebView, and we will try our best to make it seamless.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Aug 8, 2018 at 2:27 PM Frederico Galvão
> > >> >  wrote:
> > >> > >
> > >> > > My impression as a user on this is that, since the very first few
> > >> > > prototypes with WKWebView from Shazron and some others, to later
> > >the
> > >> Ionic
> > >> > > attempts at solving/masking the usual issues, to the current
> > >situation
> > >> > > whe

Re: Dealing with deprecated repos

[Shazron]

Formal as in this is our policy. From what Julio Cesar Sanchez said earlier:
"This is the deprecation policy from cordova-plugin-contacts

Deprecation Notice
This plugin is being deprecated. No more work will be done on this plugin
by the Cordova development community. You can continue to use this plugin
and it should work as-is in the future but any more arising issues will not
be fixed by the Cordova community.

All the deprecated repos have a similar deprecation notice."

As to where, we just make a new page, say deprecationpolicy.html or
something, and link it from the Contribute page (as a suggestion). If
we run into this again, we point to the policy.
On Wed, Aug 8, 2018 at 6:33 PM Chris Brody  wrote:
>
> On Wed, Aug 8, 2018 at 6:15 AM Shazron  wrote:
> >
> > Let's make it formal with what we had in the repo
>
> Does this mean make the archiving process formal or make something else 
> formal?
>
> What kind of repo?
>
> > or section in the docs somewhere.
>
> The question is always where?
>
> On Wed, Aug 8, 2018 at 6:24 AM julio cesar sanchez
>  wrote:
> >
> > I wouldn't point to a fork, because that will mean we have to search for
> > the forks and decide which one is better.
>
> +1
>
> > If a better fork appears after archiving
> > we won't be able to change.
>
> I think someone else made the point that we can always unarchive in
> case of need. I suspect (and hope) we should be able to unarchive on a
> temporary basis then re-archive.
>
> > I think best option is to point to network tab of github (in case people is
>
> +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

Re: Dealing with deprecated repos

[Shazron]

Let's make it formal with what we had in the repo, perhaps a new page
or section in the docs somewhere.
On Wed, Aug 8, 2018 at 6:09 PM Jan Piotrowski  wrote:
>
> Please note that this part of the discussion with me playing devil's
> advocate - I pretty much agree with what you are saying.
>
> Is there any way users can find out about new forks of deprecated
> repos? Fork network view on Github maybe? Then adding a link to that
> in the deprecation notice would be a nice move.
>
> Any other comments regarding a possible "Cordova Deprecation Policy"
> than what Julio already wrote?
>
> -J
>
>
> 2018-08-08 11:52 GMT+02:00 julio cesar sanchez :
> > This is the deprecation policy from cordova-plugin-contacts
> >
> > Deprecation Notice
> > This plugin is being deprecated. No more work will be done on this plugin
> > by the Cordova development community. You can continue to use this plugin
> > and it should work as-is in the future but any more arising issues will not
> > be fixed by the Cordova community.
> >
> > All the deprecated repos have a similar deprecation notice.
> >
> > Other than that, I don't think we have something more official. Also, I
> > don't know were/if that message was discussed.
> >
> > What I said on my previous message is my interpretation of "work", for me
> > what I said is work, not sure if everybody agrees on that, and it's not
> > official, just my opinion. Also my opinion of Cordova Community is
> > everybody who wants to contribute, not just the committers.
> >
> > We have dozens of repos and hundreds of open PRs that we aren't able to
> > manage, so keeping the deprecated repos open for issues/PRs in case
> > somebody want to fix something will just bring frustration to those people
> > as their PRs won't be reviewed/merged. And if we plan on continuing
> > reviewing/merging on deprecated repos, why did we deprecate them on the
> > first place?
> >
> > El mié., 8 ago. 2018 a las 11:26, Jan Piotrowski ()
> > escribió:
> >
> >> Great, then this seems to be Cordova's deprecation policy. Write it
> >> down, publish it, link to it from the deprecated projects so users
> >> know about it - problem solved.
> >>
> >> Just to be on the safe side: Was this previously discussed and decided?
> >>
> >> -J
> >>
> >> 2018-08-08 10:49 GMT+02:00 julio cesar sanchez :
> >> > No, when we deprecate something it means no more work will be done on it.
> >> >
> >> > Triaging issues, reviewing and merging other people prs and continuing
> >> > doing releases it’s work. We aren’t supposed to do anything else when we
> >> > deprecate.
> >> >
> >> > People can freely create and maintain a fork, but it won’t be official
> >> and
> >> > won’t live in the Apache repo.
> >> >
> >> >
> >> > El miércoles, 8 de agosto de 2018, Jan Piotrowski 
> >> > escribió:
> >> >
> >> >> Let me play devil's advocate:
> >> >>
> >> >> Archiving means disabling everything - issues, PRs, etc.
> >> >> Don't we want to let people create PRs with bug fixes or changes (we
> >> >> may or may not choose to merge) for other people to benefit from?
> >> >>
> >> >> -J
> >> >>
> >> >> 2018-08-08 3:40 GMT+02:00 Gearóid M :
> >> >> > +1 on archiving deprecated repos, it's an easy way to make it very
> >> clear
> >> >> that it is no longer maintained
> >> >> >
> >> >> > On Wed, 8 Aug 2018, at 01:37, Chris Brody wrote:
> >> >> >> +1
> >> >> >> On Tue, Aug 7, 2018 at 11:32 AM julio cesar sanchez
> >> >> >>  wrote:
> >> >> >> >
> >> >> >> > Archived repos are read only.
> >> >> >> >
> >> >> >> > People can still clone and/or fork them, they just can't send PRs
> >> or
> >> >> create
> >> >> >> > new issues.
> >> >> >> >
> >> >> >> > I'm +1 on archiving them.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > El mar., 7 ago. 2018 a las 17:25,  escribió:
> >> >> >> >
> >> >> >> > > I suggest archiving them all and deal with any issues as they
> >> >> appear. After
> >> >> >> > > all, repos can be unarchived if necessary.
> >> >> >> > >
> >> >> >> > > Chris Brody  schrieb am Di., 7. Aug.
> >> 2018,
> >> >> 17:16:
> >> >> >> > >
> >> >> >> > > > Continuation of discussion from
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > >
> >> https://lists.apache.org/thread.html/affbc74f0ff4d34bc09657c3c302e1
> >> >> 85cc98b946d260184847fdf191@%3Cdev.cordova.apache.org%3E
> >> >> >> > > >
> >> >> >> > > > I think it is not desired to actively support deprecated
> >> repos. I
> >> >> >> > > > think the easiest solution is to simply make those repos
> >> archived.
> >> >> >> > > >
> >> >> >> > > > But what if there are people still using the deprecated repos
> >> who
> >> >> are
> >> >> >> > > > motivated to take them over?
> >> >> >> > > >
> >> >> >> > > > 
> >> >> -
> >> >> >> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> >> >> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > >
> >> >> >>
> >> >> >> 

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

If there are no further comments regarding the blog post, I will
publish it by EOD (Pacific Time) Wed August 8th, 2018
https://github.com/apache/cordova-docs/pull/867
On Wed, Aug 8, 2018 at 3:14 PM Shazron  wrote:
>
> Apple has other goals with WKWebView (a lot deals with making it more
> secure), and I doubt they are aligned with Cordova's goals (although
> they did a patch to load file urls for iOS 9 I believe, that helped us
> avoid the local webserver route). I think almost all of us know that
> WKWebView usage by Cordova is an implementation with a lot of
> patchwork, and definitely hacky, so that we can achieve feature parity
> with our usage of UIWebView.
>
> Ionic is always welcome to chime in and contribute to the blog post,
> and submit patches.
>
> Unfortunately Apple has made the choice for us. We have to move on to
> WKWebView, and we will try our best to make it seamless.
>
>
>
>
> On Wed, Aug 8, 2018 at 2:27 PM Frederico Galvão
>  wrote:
> >
> > My impression as a user on this is that, since the very first few
> > prototypes with WKWebView from Shazron and some others, to later the Ionic
> > attempts at solving/masking the usual issues, to the current situation
> > where we have a deprecated UIWebView, is still the same as it was at the
> > start: using WKWebView on Cordova feels like a scary hack.
> >
> > I understand that we might have gotten the userbase (myself included) used
> > to having an easy life by not having CORS and similar concepts since the
> > start, which now brings those concepts as a burden, instead of a standard.
> > I also understand that the deprecation window alongside our sdk support
> > window with the custom scheme handler on top make for a very tricky spot to
> > decide how to move. I also understand and follow the issues created by the
> > iOS and safari dev teams with so many hiccups along the way.
> > Even though someone who has followed cordova development up-close for a
> > very long time like me can understand all the pressure points and
> > explanations behind the current state of WKWebView, I can't dismiss this
> > feeling that "it's still not ready, still not the right time to pick it up".
> >
> > I personaly already had the unpleasure of going through `raw -> cross-walk
> > -> raw` on the android side of things (which I'm still handling with
> > database migration stuff), and I'd love for users not to have to deal with
> > this kind of decision in the near future.
> >
> > I initially thought about investing on the idea that we should mention the
> > work done by the Ionic team on this topic on the blog post PR, but I guess
> > we don't want to risk even more confusion (at what cost?).
> >
> > I don't have an answer or fix to the issues and confusions I bring here,
> > nor do I blame them on any specific cause, and I think enlightment will
> > come with time and trial only. I just hope I'm the only one that can't
> > scratch this feeling that WKWebView is a hack.
> >
> > 2018-08-03 0:29 GMT-03:00 Darryl Pogue :
> >
> > > One concern with the Oracle plugin is that it's only patching the
> > > obvious cases of XHR and fetch, but doesn't handle things like iframes
> > > being cross origin (so no accessing the parent/child document) or
> > > local image assets being cross origin when drawn to canvas (thus
> > > tainting the canvas and making it impossible to read pixel data from
> > > it). SVG icons aren't allowed to load when using  > > xlink:href="asset/icon.svg#whatever"> because that's considered cross
> > > origin. We ran into _so_ many weird cases caused by cross origin
> > > issues when we upgraded our app to WKWebView.
> > >
> > > I haven't had a chance to dig into the custom scheme stuff, but my
> > > understanding is that everything would use the custom scheme instead
> > > of file:/// and cordova-ios would have a scheme handler that would map
> > > those to filesystem files, read those files with native code, and
> > > return the data as a response. Similar in some ways to NSURLProtocol,
> > > but asynchronous and with limited access to form data.
> > >
> > > On Thu, Aug 2, 2018 at 7:44 PM Shazron  wrote:
> > > >
> > > > Our policy has been we support the currently shipping iOS version,
> > > > plus one back. This is because of device version testing complexities.
> > > > It may work on older iOS versions if we code it with the right
> > > > safeguards, but that is not guaranteed. When iOS 12 ships this fall,
> > > > we would dr

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

Apple has other goals with WKWebView (a lot deals with making it more
secure), and I doubt they are aligned with Cordova's goals (although
they did a patch to load file urls for iOS 9 I believe, that helped us
avoid the local webserver route). I think almost all of us know that
WKWebView usage by Cordova is an implementation with a lot of
patchwork, and definitely hacky, so that we can achieve feature parity
with our usage of UIWebView.

Ionic is always welcome to chime in and contribute to the blog post,
and submit patches.

Unfortunately Apple has made the choice for us. We have to move on to
WKWebView, and we will try our best to make it seamless.




On Wed, Aug 8, 2018 at 2:27 PM Frederico Galvão
 wrote:
>
> My impression as a user on this is that, since the very first few
> prototypes with WKWebView from Shazron and some others, to later the Ionic
> attempts at solving/masking the usual issues, to the current situation
> where we have a deprecated UIWebView, is still the same as it was at the
> start: using WKWebView on Cordova feels like a scary hack.
>
> I understand that we might have gotten the userbase (myself included) used
> to having an easy life by not having CORS and similar concepts since the
> start, which now brings those concepts as a burden, instead of a standard.
> I also understand that the deprecation window alongside our sdk support
> window with the custom scheme handler on top make for a very tricky spot to
> decide how to move. I also understand and follow the issues created by the
> iOS and safari dev teams with so many hiccups along the way.
> Even though someone who has followed cordova development up-close for a
> very long time like me can understand all the pressure points and
> explanations behind the current state of WKWebView, I can't dismiss this
> feeling that "it's still not ready, still not the right time to pick it up".
>
> I personaly already had the unpleasure of going through `raw -> cross-walk
> -> raw` on the android side of things (which I'm still handling with
> database migration stuff), and I'd love for users not to have to deal with
> this kind of decision in the near future.
>
> I initially thought about investing on the idea that we should mention the
> work done by the Ionic team on this topic on the blog post PR, but I guess
> we don't want to risk even more confusion (at what cost?).
>
> I don't have an answer or fix to the issues and confusions I bring here,
> nor do I blame them on any specific cause, and I think enlightment will
> come with time and trial only. I just hope I'm the only one that can't
> scratch this feeling that WKWebView is a hack.
>
> 2018-08-03 0:29 GMT-03:00 Darryl Pogue :
>
> > One concern with the Oracle plugin is that it's only patching the
> > obvious cases of XHR and fetch, but doesn't handle things like iframes
> > being cross origin (so no accessing the parent/child document) or
> > local image assets being cross origin when drawn to canvas (thus
> > tainting the canvas and making it impossible to read pixel data from
> > it). SVG icons aren't allowed to load when using  > xlink:href="asset/icon.svg#whatever"> because that's considered cross
> > origin. We ran into _so_ many weird cases caused by cross origin
> > issues when we upgraded our app to WKWebView.
> >
> > I haven't had a chance to dig into the custom scheme stuff, but my
> > understanding is that everything would use the custom scheme instead
> > of file:/// and cordova-ios would have a scheme handler that would map
> > those to filesystem files, read those files with native code, and
> > return the data as a response. Similar in some ways to NSURLProtocol,
> > but asynchronous and with limited access to form data.
> >
> > On Thu, Aug 2, 2018 at 7:44 PM Shazron  wrote:
> > >
> > > Our policy has been we support the currently shipping iOS version,
> > > plus one back. This is because of device version testing complexities.
> > > It may work on older iOS versions if we code it with the right
> > > safeguards, but that is not guaranteed. When iOS 12 ships this fall,
> > > we would drop iOS 10 support (support as in testing for it, like I
> > > said it might still work).
> > >
> > > We could do the custom scheme -- or just use the Oracle plugin since
> > > that bridges it to using NSURLConnection, which has no restrictions.
> > > This will work on any iOS version. I would opt for the easiest
> > > solution *for now* to get something out.
> > >
> > > Using cdvapp://index.html, will all future file:// references in that
> > > index.html file work, or still have the same restrictions? 

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

We definitely have to explore this more. I doubt we can ever be
perfect at the first run at it, but we've got to lay the foundation
for the eventual patches.


On Fri, Aug 3, 2018 at 11:30 AM Darryl Pogue  wrote:
>
> One concern with the Oracle plugin is that it's only patching the
> obvious cases of XHR and fetch, but doesn't handle things like iframes
> being cross origin (so no accessing the parent/child document) or
> local image assets being cross origin when drawn to canvas (thus
> tainting the canvas and making it impossible to read pixel data from
> it). SVG icons aren't allowed to load when using  xlink:href="asset/icon.svg#whatever"> because that's considered cross
> origin. We ran into _so_ many weird cases caused by cross origin
> issues when we upgraded our app to WKWebView.
>
> I haven't had a chance to dig into the custom scheme stuff, but my
> understanding is that everything would use the custom scheme instead
> of file:/// and cordova-ios would have a scheme handler that would map
> those to filesystem files, read those files with native code, and
> return the data as a response. Similar in some ways to NSURLProtocol,
> but asynchronous and with limited access to form data.
>
> On Thu, Aug 2, 2018 at 7:44 PM Shazron  wrote:
> >
> > Our policy has been we support the currently shipping iOS version,
> > plus one back. This is because of device version testing complexities.
> > It may work on older iOS versions if we code it with the right
> > safeguards, but that is not guaranteed. When iOS 12 ships this fall,
> > we would drop iOS 10 support (support as in testing for it, like I
> > said it might still work).
> >
> > We could do the custom scheme -- or just use the Oracle plugin since
> > that bridges it to using NSURLConnection, which has no restrictions.
> > This will work on any iOS version. I would opt for the easiest
> > solution *for now* to get something out.
> >
> > Using cdvapp://index.html, will all future file:// references in that
> > index.html file work, or still have the same restrictions? I'll have
> > to do some tests (unless you know already?)
> >
> > Regarding the fallback, the point of this bridge plugin is that the
> > switching is an active decision by the developer (a hard break) and is
> > to aid in migrating completely to WKWebView. If we had an automatic
> > fallback, it might be a crutch until its too late and UIWebView is
> > gone and they are surprised since it was all working "behind the
> > scenes".
> >
> > On Fri, Aug 3, 2018 at 1:22 AM Darryl Pogue  wrote:
> > >
> > > On Sun, Jul 15, 2018 at 11:39 PM Shazron  wrote:
> > > >
> > > > 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> > > > Sharing issue (CORS). There is a workaround plugin created by Oracle
> > > > (UPL licensed, which is Apache-2.0 compatible). See
> > > > https://issues.apache.org/jira/browse/CB-10143
> > >
> > > This happens because we're using file:/// URLs, which are subject to
> > > additional security restrictions in WKWebView. Every file is treated
> > > as its own origin, so a page can't make an XHR request to something
> > > like file:///etc/passwd, but that same feature also means it can't
> > > make an XHR request to ./assets/whatever.js
> > >
> > > The encouraged solution to this is to implement a custom scheme using
> > > WKURLSchemeHandler and handle serving the files from the filesystem
> > > yourself. This means the entire app would be served from something
> > > like cdvapp://index.html rather than a file:/// URL.
> > > Unfortunately, that API was only added in iOS 11, and Cordova
> > > currently supports as far back as iOS 9, and the next major will
> > > probably still want to support iOS 10?
> > >
> > > If we have the ability to swap the webview at runtime, it might be
> > > worth investigating whether it makes sense to add a custom scheme for
> > > iOS 11+ and WKWebView, and provide a way to fallback to UIWebView for
> > > iOS 10?
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] [Github Issues] Issue and PR template + Merge Conventions / Protected Branch

[Shazron]

Agree with all 3 points by Jan.

@Chris Brody I think we should make use of Github Milestones to track
related issues.
On Wed, Aug 8, 2018 at 6:59 AM Jan Piotrowski  wrote:
>
> Update to my initial email:
>
> I just noticed we actually _do_ have an issue template in use in the
> cordovs-docs repository:
> https://github.com/apache/cordova-docs/blob/master/.github/ISSUE_TEMPLATE.md
>
> J
>
> 2018-08-07 23:18 GMT+02:00 julio cesar sanchez :
> > I think us as committers should decide if the commits make sense to keep
> > all of them or squash them into one. But bug fixes should usually be only
> > one commit, and major refactors are not usually sent by non committers
> >
> > El El mar, 7 ago 2018 a las 23:02, Chris Brody 
> > escribió:
> >
> >> > > I would favor a place where a contributor can mark if s/he would
> >> > > recommend the committer should *not* use the squash option.
> >> >
> >> > That of course could be defined in the contributor guidelines or PR
> >> > template (although there it might be a bit confusing to new users that
> >> > don't know what this is talking about). Do you know how other project
> >> > handle that?
> >>
> >> Haven't seen anything like this before.
> >>
> >> > In the end it is always the decision of the committer how contributed
> >> > code makes it into the code base, so having good guidelines for us
> >> > would probably be the best solution, right?
> >>
> >> Yes. General common sense may prove to be the major principle, as I
> >> think it has in the past. For example:
> >> * Someone raises a PR with bug fixes and major refactoring in separate
> >> commits (should not be squashed)
> >> * Someone else raises a PR with a single fix, but with extra commits
> >> to fix issues with the first commit (*should* be squashed)
> >>
> >> I wonder if we can track these discussions in a better way, somehow. I
> >> have no time to help with these things right now. I think better
> >> tracking could help ensure these important tasks do not get forgotten.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] Cordova idea: integrate with fastlane?

[Shazron]

Agree with Jesse -- this is more informational and fit for a blog post
since a lot of new devs will not know about fastlane
On Wed, Aug 8, 2018 at 6:33 AM Jesse  wrote:
>
> track it in a blog post ;)
>
> Since we use cordova-docs repo for the blog, maybe an issue there would
> make the most sense.
>
>
> (Disclosure: I am a contributor to PhoneGap and PhoneGap build)
>
>
> @purplecabbage
> risingj.com
>
> On Tue, Aug 7, 2018 at 3:22 PM, Chris Brody  wrote:
>
> > Sounds good. Any suggestions how to track this one before it gets
> > forgotten?
> > On Tue, Aug 7, 2018 at 6:20 PM Jan Piotrowski 
> > wrote:
> > >
> > > Full agreement Jesse.
> > > (Although I generally think Cordova users would benefit from more
> > > links to useful tooling - but this should be discussed somewhere else)
> > >
> > > Just for the record: fastlane is not a hosted service, but just
> > > another tool you install locally.
> > > Some CI providers offer it on their service as it is simpler than to
> > > build all the mobile automation manually.
> > >
> > > (Disclosure: I am a contributor at fastlane)
> > >
> > > 2018-08-07 23:58 GMT+02:00 Jesse :
> > > > Don't forget:
> > > > https://docs.microsoft.com/en-us/appcenter/
> > > > https://build.phonegap.com/
> > > > https://www.buddybuild.com/features/ci-cd-integrations
> > > >
> > > > If they ask to be featured, then sure, lets, but I don't think we need
> > to
> > > > be chasing them.
> > > > A simple cordova blog post explaining how to get cordova working with
> > > > fastlane, et al would be great.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > > > On Tue, Aug 7, 2018 at 2:17 PM, Jan Piotrowski 
> > wrote:
> > > >
> > > >> Fastlane itself currently doesn't mention Cordova in its documentation
> > > >> and setup creation at all - there are Github issues to change that -
> > > >> so this probably would not be really appropriate as we ask for "tools"
> > > >> etc to have _proper_ Cordova support and documentation how to use it.
> > > >>
> > > >> But yes, I think fastlane could be beneficial for many Cordova users,
> > > >> especially in corporations and enterprises.
> > > >>
> > > >> Another interesting aspect of fastlane it that it uses fastlane itself
> > > >> to build, test, create releases etc. It built itself something like
> > > >> our `cordova-coho`. That could be worth investigating (one day) as it
> > > >> really works well.
> > > >>
> > > >> -J
> > > >>
> > > >> 2018-08-07 22:54 GMT+02:00 Chris Brody :
> > > >> > Nice, especialy about ionic.zone/fastlane. Shouldn't we feature
> > > >> > fastlane on cordova.io?
> > > >> > On Tue, Aug 7, 2018 at 4:03 PM Jan Piotrowski  > >
> > > >> wrote:
> > > >> >>
> > > >> >> What exactly do you mean by "integrate"?
> > > >> >>
> > > >> >> Apps built with Cordova (and Ionic) are pretty well supported by
> > > >> >> Fastlane, /platforms/ios|android are just native projects after
> > all -
> > > >> >> even though you have to take some extra measures to handle the
> > > >> >> generated projects. I wrote some articles about how can work:
> > > >> >> https://ionic.zone/fastlane
> > > >> >>
> > > >> >> J
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> 2018-08-07 21:38 GMT+02:00 Chris Brody :
> > > >> >> > Should we explore this idea for Android & 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
> > > >> >>
> > > >> >
> > > >> > 
> > -
> > > >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > >> > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >> >
> > > >>
> > > >> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >>
> > > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >

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

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Shazron]

We could whip something up using https://glitch.com for a start
On Wed, Aug 8, 2018 at 11:34 AM Shazron  wrote:
>
> Thanks Jan!
>
> 1. Should we just disable those then? One other way is to add in bold
> big letters about the deprecation in the New Issue template
> 2. These links are super useful. Perhaps they should be on the
> website, what do you all think? Not sure if the scripting for the
> second link is server side or it could be client side as well (via
> JavaScript). Perhaps on the https://cordova.apache.org/contribute/
> (contribute.cordova.io) page. That massive github link could also be
> auto-generated as well on that page, somehow. Let me know how I can
> help.
> On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski  wrote:
> >
> > You may have noticed the first issues coming in on some repositories.
> >
> > 1. In hindsight enabling issues for deprecated platforms, plugins etc
> > may not have been the smartest decision. We will have to find out how
> > to handle this - we should probably write down a "deprecation /
> > archivation policy" anyway.
> >
> > 2. Some people are missing the "all tickets in one view" interface. I
> > quickly built http://cordova.betamo.de/ as a workaround.
> > The second link on there generates a few prepared Github search links,
> > including one that is valid for _all_ Cordova repositories:
> > https://github.com/issues?q=type%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordova-plugin-compat+repo%3Aapache%2Fcordova-registry-web+repo%3Aapache%2Fcordova-registry+repo%3Aapache%2Fcordova-fauxton-server=created=Issues
> > Nice, isn't it?
> > Do you have any specific requests for filters or interface you need or
> > want? What did you use in JIRA that you couldn't find for Github?
> > Shouldn't be too hard to whip something up.
> >
> > -J
> >
> >
> >
> >
> > 2018-08-06 16:05 GMT+02:00 Jan Piotrowski :
> > > That worked, the ticket was just resolved and issues are now enabled
> > > for all repos (beside cordova-weinre which is archived):
> > >
> > > https://github.com/apache/cordova-android/issues
> > > https://github.com/apache/cordova-ios/issues
> > > https://github.com/apache/cordova-plugin-inappbrowser/issues
> > > ...
> > >
> > > On to b), c) etc.
> > >
> > > 2018-08-06 13:09 GMT+02:00 Chris Brody :
> > >> On Mo

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Shazron]

Thanks Jan!

1. Should we just disable those then? One other way is to add in bold
big letters about the deprecation in the New Issue template
2. These links are super useful. Perhaps they should be on the
website, what do you all think? Not sure if the scripting for the
second link is server side or it could be client side as well (via
JavaScript). Perhaps on the https://cordova.apache.org/contribute/
(contribute.cordova.io) page. That massive github link could also be
auto-generated as well on that page, somehow. Let me know how I can
help.
On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski  wrote:
>
> You may have noticed the first issues coming in on some repositories.
>
> 1. In hindsight enabling issues for deprecated platforms, plugins etc
> may not have been the smartest decision. We will have to find out how
> to handle this - we should probably write down a "deprecation /
> archivation policy" anyway.
>
> 2. Some people are missing the "all tickets in one view" interface. I
> quickly built http://cordova.betamo.de/ as a workaround.
> The second link on there generates a few prepared Github search links,
> including one that is valid for _all_ Cordova repositories:
> https://github.com/issues?q=type%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordova-plugin-compat+repo%3Aapache%2Fcordova-registry-web+repo%3Aapache%2Fcordova-registry+repo%3Aapache%2Fcordova-fauxton-server=created=Issues
> Nice, isn't it?
> Do you have any specific requests for filters or interface you need or
> want? What did you use in JIRA that you couldn't find for Github?
> Shouldn't be too hard to whip something up.
>
> -J
>
>
>
>
> 2018-08-06 16:05 GMT+02:00 Jan Piotrowski :
> > That worked, the ticket was just resolved and issues are now enabled
> > for all repos (beside cordova-weinre which is archived):
> >
> > https://github.com/apache/cordova-android/issues
> > https://github.com/apache/cordova-ios/issues
> > https://github.com/apache/cordova-plugin-inappbrowser/issues
> > ...
> >
> > On to b), c) etc.
> >
> > 2018-08-06 13:09 GMT+02:00 Chris Brody :
> >> On Mon, Aug 6, 2018 at 6:48 AM Jan Piotrowski  wrote:
> >>>
> >>> Created INFRA issue at https://issues.apache.org/jira/browse/INFRA-16876
> >>
> >> +100
> >>
> >> -
> >> 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: 

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

Our policy has been we support the currently shipping iOS version,
plus one back. This is because of device version testing complexities.
It may work on older iOS versions if we code it with the right
safeguards, but that is not guaranteed. When iOS 12 ships this fall,
we would drop iOS 10 support (support as in testing for it, like I
said it might still work).

We could do the custom scheme -- or just use the Oracle plugin since
that bridges it to using NSURLConnection, which has no restrictions.
This will work on any iOS version. I would opt for the easiest
solution *for now* to get something out.

Using cdvapp://index.html, will all future file:// references in that
index.html file work, or still have the same restrictions? I'll have
to do some tests (unless you know already?)

Regarding the fallback, the point of this bridge plugin is that the
switching is an active decision by the developer (a hard break) and is
to aid in migrating completely to WKWebView. If we had an automatic
fallback, it might be a crutch until its too late and UIWebView is
gone and they are surprised since it was all working "behind the
scenes".

On Fri, Aug 3, 2018 at 1:22 AM Darryl Pogue  wrote:
>
> On Sun, Jul 15, 2018 at 11:39 PM Shazron  wrote:
> >
> > 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> > Sharing issue (CORS). There is a workaround plugin created by Oracle
> > (UPL licensed, which is Apache-2.0 compatible). See
> > https://issues.apache.org/jira/browse/CB-10143
>
> This happens because we're using file:/// URLs, which are subject to
> additional security restrictions in WKWebView. Every file is treated
> as its own origin, so a page can't make an XHR request to something
> like file:///etc/passwd, but that same feature also means it can't
> make an XHR request to ./assets/whatever.js
>
> The encouraged solution to this is to implement a custom scheme using
> WKURLSchemeHandler and handle serving the files from the filesystem
> yourself. This means the entire app would be served from something
> like cdvapp://index.html rather than a file:/// URL.
> Unfortunately, that API was only added in iOS 11, and Cordova
> currently supports as far back as iOS 9, and the next major will
> probably still want to support iOS 10?
>
> If we have the ability to swap the webview at runtime, it might be
> worth investigating whether it makes sense to add a custom scheme for
> iOS 11+ and WKWebView, and provide a way to fallback to UIWebView for
> iOS 10?
>
> -
> 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: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

We could -- I can just add a suffix or prefix...
On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski  wrote:
>
> Couldn't the class names be changed when integrating the plugin?
> Because the console stuff is still messing with people :/
>
> 2018-08-02 17:01 GMT+02:00 Shazron :
> > yup, the class name conflict is unavoidable -- it's like when we
> > integrated the console plugin.
> >
> > The bridge plugin will be able to load any webview engine plugin that
> > has already been installed, not just the main 2. I didn't want to
> > confuse people with too much information, since this is not an Ionic
> > blog post.
> > On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez
> >  wrote:
> >>
> >> As long as we don't break pluggable webviews, I don't think it's needed,
> >> there are other wkwebview plugins (from telerik, oracle, etc).
> >>
> >> But as some (or all) of them started as forks, there will be probably
> >> problems with duplicate class names.
> >>
> >> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski :
> >>
> >> > Many Cordova users out there are probably using
> >> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
> >> > play any role in regards to the blog post? Should this maybe be
> >> > mentioned as an anticipated question?
> >> >
> >> > 2018-08-02 16:31 GMT+02:00 Shazron :
> >> > > Please review the draft of the blog post about this:
> >> > > "The Future of the iOS WebView in Apache Cordova"
> >> > > https://github.com/apache/cordova-docs/pull/867
> >> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
> >> > >>
> >> > >> I've done with my review with all the issues that need to resolved
> >> > >> with the plugin before it can be baked in to the platform for a major
> >> > >> version release. I'm going to discuss issues with respect to migration
> >> > >> of developers from UIWebView (features that will be lost or are
> >> > >> different)
> >> > >>
> >> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has
> >> > >> created a plugin for a workaround. See
> >> > >> https://issues.apache.org/jira/browse/CB-12074
> >> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
> >> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
> >> > >> 3. Can't execute JavaScript code in the background. There are several
> >> > >> issues related to this. See
> >> > >> https://issues.apache.org/jira/browse/CB-12815
> >> > >> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> >> > >> Sharing issue (CORS). There is a workaround plugin created by Oracle
> >> > >> (UPL licensed, which is Apache-2.0 compatible). See
> >> > >> https://issues.apache.org/jira/browse/CB-10143
> >> > >> 5. Migration of localStorage from UIWebView. There is a migration
> >> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974
> >> > >>
> >> > >> Of course there are several bugs also that need to be resolved. List
> >> > >> here: https://s.apache.org/QfsF
> >> > >>
> >> > >> Out of the 5 issues, 3 (external) plugins are available for the
> >> > >> issues, 2 require minor code changes.
> >> > >>
> >> > >> For a solution to issue 5, I am proposing a proxy webview engine
> >> > >> plugin that will:
> >> > >> 1. Read a preference to use a particular webview engine
> >> > >> 2. Proxy the selected webview engine's interface from its interface
> >> > >>
> >> > >> This proxy will possibly help with migration and testing, so users can
> >> > >> "beta test" WKWebView now for existing apps (and switch back if there
> >> > >> are problems). This is like a "feature flag" that I mentioned before,
> >> > >> but at runtime, for users.
> >> > >>
> >> > >> This proxy webview engine plugin can also possibly help with
> >> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a
> >> > >> webview's interface).
> >> > >
> >> > > -
> >> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> >> > >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >> >
> >> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: ios-deploy questions

[Shazron]

1. Previously we had node_modules bundled. We couldn't bundle
ios-deploy because of its viral license. The only issue is that it
tries to build on Windows, but that should be easily fixed:
https://github.com/ios-control/ios-deploy/issues/355 . There should be
no problem in using a dependency from the command line, we just have
to prepend the path from `npm bin` to the PATH variable, then run the
executable (just have to exclude Windows from this case).
2. The risk mismatch is only based off the Xcode version installed
since it is built natively and relies on Xcode frameworks (Xcode 9.4
was missing files and ios-deploy had to work around it). We don't
really have a matrix of dependencies, so the latest is always used for
ios-deploy.

Technically we don't even have to install anything now, if we prefix
the npm command with `npx`:
`npx ios-deploy a b c`

npx has been available since npm@5.2.0
According to this: https://nodejs.org/en/download/releases/ it would
mean that we can only rely on npx being installed if the user has node
8.2.0, which is a ways off from being our default node version.

On Thu, Aug 2, 2018 at 10:41 PM Jan Piotrowski  wrote:
>
> > 1. Why not make ios-deploy a dependency of cordova-ios that would then
> > be automatically installed?
>
> Historically, I think, commands that should be able to be called via
> the command line had to be installed globally with npm to work. Is
> this not the case any more?
>
> 2018-08-02 15:26 GMT+02:00 Chris Brody :
> > A couple things that I think are not clear for
> > :
> >
> > 1. Why not make ios-deploy a dependency of cordova-ios that would then
> > be automatically installed?
> >
> > 2. Is there a risk of mismatch between a users installed ios-deploy
> > version and a users Cordova version? Should this be documented, if so?
> >
> > I think the answer to 1 is that ios-deploy sometimes needs to be
> > installed with more system privs. I am not 100% sure of this, would
> > love some confirmation from an expert. And I think this is not really
> > a problem most of the time.
> >
> > I think the answer to 2 is "not yet".
> >
> > Confirmation would be really helpful.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

yup, the class name conflict is unavoidable -- it's like when we
integrated the console plugin.

The bridge plugin will be able to load any webview engine plugin that
has already been installed, not just the main 2. I didn't want to
confuse people with too much information, since this is not an Ionic
blog post.
On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez
 wrote:
>
> As long as we don't break pluggable webviews, I don't think it's needed,
> there are other wkwebview plugins (from telerik, oracle, etc).
>
> But as some (or all) of them started as forks, there will be probably
> problems with duplicate class names.
>
> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski :
>
> > Many Cordova users out there are probably using
> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
> > play any role in regards to the blog post? Should this maybe be
> > mentioned as an anticipated question?
> >
> > 2018-08-02 16:31 GMT+02:00 Shazron :
> > > Please review the draft of the blog post about this:
> > > "The Future of the iOS WebView in Apache Cordova"
> > > https://github.com/apache/cordova-docs/pull/867
> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
> > >>
> > >> I've done with my review with all the issues that need to resolved
> > >> with the plugin before it can be baked in to the platform for a major
> > >> version release. I'm going to discuss issues with respect to migration
> > >> of developers from UIWebView (features that will be lost or are
> > >> different)
> > >>
> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has
> > >> created a plugin for a workaround. See
> > >> https://issues.apache.org/jira/browse/CB-12074
> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
> > >> 3. Can't execute JavaScript code in the background. There are several
> > >> issues related to this. See
> > >> https://issues.apache.org/jira/browse/CB-12815
> > >> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> > >> Sharing issue (CORS). There is a workaround plugin created by Oracle
> > >> (UPL licensed, which is Apache-2.0 compatible). See
> > >> https://issues.apache.org/jira/browse/CB-10143
> > >> 5. Migration of localStorage from UIWebView. There is a migration
> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974
> > >>
> > >> Of course there are several bugs also that need to be resolved. List
> > >> here: https://s.apache.org/QfsF
> > >>
> > >> Out of the 5 issues, 3 (external) plugins are available for the
> > >> issues, 2 require minor code changes.
> > >>
> > >> For a solution to issue 5, I am proposing a proxy webview engine
> > >> plugin that will:
> > >> 1. Read a preference to use a particular webview engine
> > >> 2. Proxy the selected webview engine's interface from its interface
> > >>
> > >> This proxy will possibly help with migration and testing, so users can
> > >> "beta test" WKWebView now for existing apps (and switch back if there
> > >> are problems). This is like a "feature flag" that I mentioned before,
> > >> but at runtime, for users.
> > >>
> > >> This proxy webview engine plugin can also possibly help with
> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a
> > >> webview's interface).
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >

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

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

Please review the draft of the blog post about this:
"The Future of the iOS WebView in Apache Cordova"
https://github.com/apache/cordova-docs/pull/867
On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
>
> I've done with my review with all the issues that need to resolved
> with the plugin before it can be baked in to the platform for a major
> version release. I'm going to discuss issues with respect to migration
> of developers from UIWebView (features that will be lost or are
> different)
>
> 1. Cookies don't persist. This is a WebKit bug, but someone has
> created a plugin for a workaround. See
> https://issues.apache.org/jira/browse/CB-12074
> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
> 3. Can't execute JavaScript code in the background. There are several
> issues related to this. See
> https://issues.apache.org/jira/browse/CB-12815
> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> Sharing issue (CORS). There is a workaround plugin created by Oracle
> (UPL licensed, which is Apache-2.0 compatible). See
> https://issues.apache.org/jira/browse/CB-10143
> 5. Migration of localStorage from UIWebView. There is a migration
> plugin available. See https://issues.apache.org/jira/browse/CB-11974
>
> Of course there are several bugs also that need to be resolved. List
> here: https://s.apache.org/QfsF
>
> Out of the 5 issues, 3 (external) plugins are available for the
> issues, 2 require minor code changes.
>
> For a solution to issue 5, I am proposing a proxy webview engine
> plugin that will:
> 1. Read a preference to use a particular webview engine
> 2. Proxy the selected webview engine's interface from its interface
>
> This proxy will possibly help with migration and testing, so users can
> "beta test" WKWebView now for existing apps (and switch back if there
> are problems). This is like a "feature flag" that I mentioned before,
> but at runtime, for users.
>
> This proxy webview engine plugin can also possibly help with
> InAppBrowser, I'm not sure (since that plugin has more hooks into a
> webview's interface).

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

Re: Commit package-lock.json in next major Cordova release or not?

[Shazron]

yes +1
On Thu, Aug 2, 2018 at 4:28 AM Chris Brody  wrote:
>
> I think we should start to commit package-lock.json in the next major
> release but am not 100% sure. My understanding is that
> package-lock.json mostly serves a couple major purposes:
> * preserve the structure of node_modules cross-platform
> * use SHA numbers to verify correct packages
>
> There seem to have been changes between npm@4 (??), npm@5, and npm@6,
> as described in the following:
> * https://github.com/npm/npm/issues/20434 (npm@5 vs npm@6)
> * https://jpospisil.com/2017/06/02/understanding-lock-files-in-npm-5.html
>
> From what I read I think npm@5 & npm@6 would continue to follow the
> semver rules for packages specified in package.json.
>
> Major advantages I can think of:
> * better consistency for cross-platform development
> * no need to regenerate package-lock.json for npm audit check
>
> But I can think of the following possible disadvantages to consider:
> * not as easy to update dependencies, probably not possible to just
> update dependencies by hand
> * some additional "noise" in the git history, shouldn't be too bad though
> * possibly major: in case people work on different dependency changes
> in parallel and want to merge by git merge, rebase, or cherry-pick
> dealing with the package-lock.json changes may not be so clean
>
> and a counter-point:
> * 
> https://www.codementor.io/johnkennedy/get-rid-of-that-npm-package-lock-json-e0bj7ai42
>
> -
> 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: Any reason to support Xcode pre-9 on cordova-ios@4 or cordova-osx?

[Shazron]

No to all.
On Thu, Aug 2, 2018 at 11:54 AM Chris Brody  wrote:
>
> From https://github.com/apache/cordova-docs/issues/863 it is clear
> that we are not allowed to use Xcode pre-9.0 with Apple's App Store. I
> suspect there are also not too many volunteers testing on Xcode
> pre-9.0. I just raised CB-14245 to drop support for Xcode pre-9.0.
>
> Open questions on my side:
> * Any reason not to drop Xcode pre-9.0 from cordova-ios@latest (4.5.x)
> & Cordova 8.x iOS docs?
> * Any reason not to drop Xcode pre-9.0 from next major release of cordova-osx?
> * Any reason not to drop Xcode pre-9.0 from cordova-osx@latest (4.0.x)
> & Cordova 8.x OSX docs?
>
> Thanks to PMC members for the answers of my other questions so far.
>
> -
> 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-wndroid@6.0.1 patch release

[Shazron]

The subject says "[VOTE] cordova-wndroid@6.0.1 patch release". A bit
ambiguous, I propose re-doing the vote.
On Sat, Jul 28, 2018 at 7:23 AM Chris Brody  wrote:
>
> Please review and vote on this 6.0.1 Windows patch release by replying
> to this email (and keep discussion on the DISCUSS thread).
>
> Release issue: https://issues.apache.org/jira/browse/CB-14226
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-14226/
>
> The package was published from its corresponding git tag:
>
> cordova-windows: 6.0.1 (cc4733ef64)
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-windows#6.0.1
>
> Upon a successful vote I will upload the archive to dist/, publish it
> to npm, and post the blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and
> subdependencies have Apache-compatible licenses
> * Ensured continuous build was green when repo was tagged
> * tested with cordova-sqlite-storage plugin using node@4.9.1,
> npm@2.15.11 and node@8.11.3, npm@5.6.0 - more details in:
> https://github.com/apache/cordova-windows/pull/287
>
> Proposed blog post in: https://github.com/apache/cordova-docs/pull/854
>
> -
> 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: Dealing with cordova-windows license header audit issue

[Shazron]

+1 to your proposal. I added a review comment in two of the PRs.
On Fri, Jul 27, 2018 at 9:06 AM Chris Brody  wrote:
>
> While getting ready to make a cordova-windows patch release I
> discovered that coho audit-license-headers flags an issue with
> template/Properties/Default.rd.xml ([1]). Proposed solution is to add
> the needed license header to template/Properties/Default.rd.xml in the
> patch release as proposed in [2] then fix in upcoming release as
> proposed in [3,4]. Alternatives are discussed in [5].
>
> I would personally favor fixing as proposed in [2,3,4] and consider if
> we can remove this file as discussed in [5].
>
> Feedback in [5] or this thread would be really appreciated. I would
> like to make the cordova-windows patch release within the next few
> days, hopefully by the end of July 2018.
>
> Thanks and best regards,
>
> Chris
>
> [1] 
> [2] 
> [3] 
> [4] 
> [5] 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] cordova--ios 4.5.5 patch release

[Shazron]

Yes 1.9.3 has the fixes. For the future build just update the check_reqs
version.

But it’s not critical since this error is only during build time of the
binary — if they already have this installed it won’t affect them (and if
they don’t — they will get the latest anyway)

On Tue, Jul 24, 2018 at 10:18 PM Chris Brody  wrote:

> Thanks Shazron for your efforts to deal with ios-deploy. I would like
> to get ios-deploy with the latest fixes in the build of cordova-ios,
> hopefully in the near future (don't want to delay this one). Am I
> right that ios-deploy@1.9.3 would resolve the issues discovered here?
> On Tue, Jul 24, 2018 at 3:56 AM Shazron  wrote:
> >
> > I've fixed the ios-deploy issue with a new 1.9.3 release, so that
> > shouldn't affect things anymore.
> > On Tue, Jul 24, 2018 at 11:43 AM Shazron  wrote:
> > >
> > > https://github.com/ios-control/ios-deploy/issues/349
> > > On Tue, Jul 24, 2018 at 11:38 AM Shazron  wrote:
> > > >
> > > > Some issues , related to an external tool ios-deploy that we use:
> > > > node 8.11.2
> > > > (note that issues are only related to running and building for
> device,
> > > > related to the ios-deploy tool that we use. Emulator is fine)
> > > >
> > > > I don't think this should hold up the release.
> > > >
> > > > 1. ---
> > > > # this defaults to building for device and emulator; I had a device
> plugged in
> > > > # error does not show if you don't have a device plugged in
> > > > # cordova build --emulator is fine
> > > > $ cordova build
> > > > (node:18179) UnhandledPromiseRejectionWarning: ios-deploy was not
> > > > found. Please download, build and install version 1.9.2 or greater
> > > > from https://github.com/phonegap/ios-deploy into your path, or do
> 'npm
> > > > install -g ios-deploy'
> > > > (node:18179) UnhandledPromiseRejectionWarning: Unhandled promise
> > > > rejection. This error originated either by throwing inside of an
> async
> > > > function without a catch block, or by rejecting a promise which was
> > > > not handled with .catch(). (rejection id: 1)
> > > > (node:18179) [DEP0018] DeprecationWarning: Unhandled promise
> > > > rejections are deprecated. In the future, promise rejections that are
> > > > not handled will terminate the Node.js process with a non-zero exit
> > > > code.
> > > >
> > > > Getting three unhandled promise rejections.
> > > >
> > > > 2. ---
> > > > ios-deploy cannot be installed, I haven't checked the issue tracker
> > > > for it lately but I think there has been issues filed, that I have to
> > > > now address. The error is:
> > > >
> > > > cp:
> /System/Library/PrivateFrameworks/MobileDevice.framework/XPCServices:
> > > > No such file or directory
> > > > ** BUILD FAILED **
> >
> > -
> > 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-ios 4.5.5 patch release

[Shazron]

I vote +1:
- Could create a blank iOS project
- Could run the iOS project in the simulator and device
On Tue, Jul 24, 2018 at 5:12 AM Chris Brody  wrote:
>
> Please review and vote on this cordova-ios 4.5.5 patch release by
> replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-14217
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-14217/
>
> The package was published from its corresponding git tag:
>
> cordova-ios: 4.5.5 (0c2b24718a)
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-ios#4.5.5
>
> 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:
> * Verified that npm audit shows 0 vulnerabilities
> * 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
> * Other tests listed in: https://github.com/apache/cordova-ios/pull/381
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] cordova--ios 4.5.5 patch release

[Shazron]

I've fixed the ios-deploy issue with a new 1.9.3 release, so that
shouldn't affect things anymore.
On Tue, Jul 24, 2018 at 11:43 AM Shazron  wrote:
>
> https://github.com/ios-control/ios-deploy/issues/349
> On Tue, Jul 24, 2018 at 11:38 AM Shazron  wrote:
> >
> > Some issues , related to an external tool ios-deploy that we use:
> > node 8.11.2
> > (note that issues are only related to running and building for device,
> > related to the ios-deploy tool that we use. Emulator is fine)
> >
> > I don't think this should hold up the release.
> >
> > 1. ---
> > # this defaults to building for device and emulator; I had a device plugged 
> > in
> > # error does not show if you don't have a device plugged in
> > # cordova build --emulator is fine
> > $ cordova build
> > (node:18179) UnhandledPromiseRejectionWarning: ios-deploy was not
> > found. Please download, build and install version 1.9.2 or greater
> > from https://github.com/phonegap/ios-deploy into your path, or do 'npm
> > install -g ios-deploy'
> > (node:18179) UnhandledPromiseRejectionWarning: Unhandled promise
> > rejection. This error originated either by throwing inside of an async
> > function without a catch block, or by rejecting a promise which was
> > not handled with .catch(). (rejection id: 1)
> > (node:18179) [DEP0018] DeprecationWarning: Unhandled promise
> > rejections are deprecated. In the future, promise rejections that are
> > not handled will terminate the Node.js process with a non-zero exit
> > code.
> >
> > Getting three unhandled promise rejections.
> >
> > 2. ---
> > ios-deploy cannot be installed, I haven't checked the issue tracker
> > for it lately but I think there has been issues filed, that I have to
> > now address. The error is:
> >
> > cp: /System/Library/PrivateFrameworks/MobileDevice.framework/XPCServices:
> > No such file or directory
> > ** BUILD FAILED **

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

Re: [DISCUSS] cordova--ios 4.5.5 patch release

[Shazron]

https://github.com/ios-control/ios-deploy/issues/349
On Tue, Jul 24, 2018 at 11:38 AM Shazron  wrote:
>
> Some issues , related to an external tool ios-deploy that we use:
> node 8.11.2
> (note that issues are only related to running and building for device,
> related to the ios-deploy tool that we use. Emulator is fine)
>
> I don't think this should hold up the release.
>
> 1. ---
> # this defaults to building for device and emulator; I had a device plugged in
> # error does not show if you don't have a device plugged in
> # cordova build --emulator is fine
> $ cordova build
> (node:18179) UnhandledPromiseRejectionWarning: ios-deploy was not
> found. Please download, build and install version 1.9.2 or greater
> from https://github.com/phonegap/ios-deploy into your path, or do 'npm
> install -g ios-deploy'
> (node:18179) UnhandledPromiseRejectionWarning: Unhandled promise
> rejection. This error originated either by throwing inside of an async
> function without a catch block, or by rejecting a promise which was
> not handled with .catch(). (rejection id: 1)
> (node:18179) [DEP0018] DeprecationWarning: Unhandled promise
> rejections are deprecated. In the future, promise rejections that are
> not handled will terminate the Node.js process with a non-zero exit
> code.
>
> Getting three unhandled promise rejections.
>
> 2. ---
> ios-deploy cannot be installed, I haven't checked the issue tracker
> for it lately but I think there has been issues filed, that I have to
> now address. The error is:
>
> cp: /System/Library/PrivateFrameworks/MobileDevice.framework/XPCServices:
> No such file or directory
> ** BUILD FAILED **

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

[DISCUSS] cordova--ios 4.5.5 patch release

[Shazron]

Some issues , related to an external tool ios-deploy that we use:
node 8.11.2
(note that issues are only related to running and building for device,
related to the ios-deploy tool that we use. Emulator is fine)

I don't think this should hold up the release.

1. ---
# this defaults to building for device and emulator; I had a device plugged in
# error does not show if you don't have a device plugged in
# cordova build --emulator is fine
$ cordova build
(node:18179) UnhandledPromiseRejectionWarning: ios-deploy was not
found. Please download, build and install version 1.9.2 or greater
from https://github.com/phonegap/ios-deploy into your path, or do 'npm
install -g ios-deploy'
(node:18179) UnhandledPromiseRejectionWarning: Unhandled promise
rejection. This error originated either by throwing inside of an async
function without a catch block, or by rejecting a promise which was
not handled with .catch(). (rejection id: 1)
(node:18179) [DEP0018] DeprecationWarning: Unhandled promise
rejections are deprecated. In the future, promise rejections that are
not handled will terminate the Node.js process with a non-zero exit
code.

Getting three unhandled promise rejections.

2. ---
ios-deploy cannot be installed, I haven't checked the issue tracker
for it lately but I think there has been issues filed, that I have to
now address. The error is:

cp: /System/Library/PrivateFrameworks/MobileDevice.framework/XPCServices:
No such file or directory
** BUILD FAILED **

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

Re: Reviving Face-to-Face video meetings?

[Shazron]

+1!
On Thu, Jul 19, 2018 at 1:17 PM Bryan Ellis  wrote:
>
> I also believe that this is a great idea and would be interested in
> participating.
>
> Anytime between now and August 3rd will work for me.
>
> On Thu, Jul 19, 2018 at 10:50 AM Gearóid M  wrote:
>
> > Great idea, I'd like to get to know the Cordova contributors. I probably
> > will not be available in the next few weeks, but I would like to join in
> > in the future if it becomes a regular occurrence.
> >
> > On 2018/07/18 3:59, raphine...@gmail.com wrote:
> > > Definitely!
> > >
> > > Chris Brody  schrieb am Di., 17. Juli 2018,
> > 20:30:
> > >
> > >> +1, would be really nice!
> > >> On Tue, Jul 17, 2018 at 2:19 PM Darryl Pogue  wrote:
> > >>> Hey folks,
> > >>>
> > >>> In the days of old, the Cordova project tried to have semi-regular
> > >>> video conference meetings on Hangouts for coordinating work and
> > >>> getting to know fellow collaborators a bit better. Those dropped off
> > >>> as people became less active on the project, but with a bunch of new
> > >>> and eager faces it probably makes sense to set up a meeting to discuss
> > >>> the roadmap and release timeline.
> > >>>
> > >>> Historically we used Google Hangouts because there was a way to make
> > >>> the meeting publicly viewable, but we could also use
> > >>> Skype/Zoom/whatever is popular these days. Ideally something that can
> > >>> just work by clicking a link.
> > >>>
> > >>> We have a wide range on contributors from across the globe, but we
> > >>> will try our best to find a time that works for as many people as
> > >>> possible. Let's gauge interest and pick a rough timeframe and then we
> > >>> can set up a Doodle poll for people to pick specific hours.
> > >>>
> > >>> Is there interest in trying to schedule a video call sometime between
> > >>> now and August 3rd?
> > >>>
> > >>> ~Darryl
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >>> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >

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

Re: http error 404 retrieving version 3.6.3 for www

[Shazron]

This is a dev list for developing on Cordova itself, not a user list.

Please file an issue at issues.cordova.io if its a bug with complete
repro steps. Judging with what vague info you've presented, it is not
enough.
On Thu, Jul 19, 2018 at 10:26 AM Roshan Agrawal  wrote:
>
> Hello Team,
>
> I am facing this issue while creating my first cordova project and I am not
> getting any help. I tried installing latest cordova version but the same
> doesnot work. I tried installing 3.6.3 but it is not present. I tried
> installing 3.6.3-0.2.13 but the issue still persist.
>
>
> Where is this www? how to resolve this issue
>
> --
>
>
>
> “Don’t aim for success if you want it; just do what you love and believe
> in, and it will come naturally.”
>
> Thanks and Regards,
> Roshan Agrawal
> Mobile No.: +91 94 05 872111

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

Re: Nightly builds

[Shazron]

Thanks Darryl!
On Thu, Jul 19, 2018 at 1:05 PM Darryl Pogue  wrote:
>
> Apologies for the Jenkins spam, the builds were failing after npm
> revoked all auth tokens and we needed to reauthenticate.
>
> I've figured that part out, so our nightly builds are back to usually
> failing for flaky reasons instead of consistently failing for auth
> reasons. It's an improvement... of sorts...
>
> ~Darryl
>
> -
> 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: https redirect needed

[Shazron]

Thanks!
https://issues.apache.org/jira/browse/CB-14210


On Tue, Jul 17, 2018 at 2:21 AM  wrote:
>
> Depending on how the site is deployed, you might need
> https://stackoverflow.com/a/37006232/380229
>
> Full disclosure: that's an answer by me.
>
> Shazron  schrieb am Mo., 16. Juli 2018, 07:50:
>
> > How:
> > https://stackoverflow.com/a/13376283
> >
> > Where:
> > https://svn.apache.org/repos/asf/cordova/site/public/.htaccess
> >
> >
> > On Mon, Jul 16, 2018 at 11:21 AM Shazron  wrote:
> > >
> > > I've made the redirect changes for the naked domain, as well as www
> > subdomain.
> > >
> > > Redirecting http://c.a.o to https://c.a.o - we will have to configure
> > > .htaccess ourselves (there will be no foundation-wide redirects
> > >
> > https://issues.apache.org/jira/browse/INFRA-15493?jql=text%20~%20%22http%20redirect%22
> > )
> > >
> > > Regarding https://cordova.io  I'm not sure how to do this since it's
> > > just a 302 Redirect on the DNS level.
> > > On Thu, Jul 12, 2018 at 9:33 PM Chris Brody 
> > wrote:
> > > >
> > > > If I navigate to http://cordova.io/, www.cordova.io, or
> > > > http://cordova.apache.org/ on Chrome (Chromium) here is what happend:
> > > > * it goes to http://cordova.apache.org/.
> > > > * I see an "i" circle in the address bar
> > > > * if I click it, it tells me that my connection is not secure
> > > >
> > > > It has already been announced that Chrome will mark sites like this as
> > > > "not secure" starting very soon.
> > > >
> > > > But navigating to https://cordova.apache.org/ works as expected.
> > > >
> > > > I think the right solution is to simply redirect http://cordova.io/,
> > > > www.cordova.io, and http://cordova.apache.org/ to the https site.
> > > >
> > > > An additional point is that if I would try navigating to
> > > > https://cordova.io I I get a message that the certificate is not
> > > > valid. Should be easy to fix with help from letsencrypt.org:)
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >

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

Re: https redirect needed

[Shazron]

This is because I haven't done the .htaccess changes yet

On Mon, Jul 16, 2018 at 7:42 PM Chris Brody  wrote:

> http://cordova.apache.org/ still does not seem to be redirected; the
> others look good
>
> Wondering if they should do something in the Apache org itself for the
> other project pages?
> On Mon, Jul 16, 2018 at 1:50 AM Shazron  wrote:
> >
> > How:
> > https://stackoverflow.com/a/13376283
> >
> > Where:
> > https://svn.apache.org/repos/asf/cordova/site/public/.htaccess
> >
> >
> > On Mon, Jul 16, 2018 at 11:21 AM Shazron  wrote:
> > >
> > > I've made the redirect changes for the naked domain, as well as www
> subdomain.
> > >
> > > Redirecting http://c.a.o to https://c.a.o - we will have to configure
> > > .htaccess ourselves (there will be no foundation-wide redirects
> > >
> https://issues.apache.org/jira/browse/INFRA-15493?jql=text%20~%20%22http%20redirect%22
> )
> > >
> > > Regarding https://cordova.io  I'm not sure how to do this since it's
> > > just a 302 Redirect on the DNS level.
> > > On Thu, Jul 12, 2018 at 9:33 PM Chris Brody 
> wrote:
> > > >
> > > > If I navigate to http://cordova.io/, www.cordova.io, or
> > > > http://cordova.apache.org/ on Chrome (Chromium) here is what
> happend:
> > > > * it goes to http://cordova.apache.org/.
> > > > * I see an "i" circle in the address bar
> > > > * if I click it, it tells me that my connection is not secure
> > > >
> > > > It has already been announced that Chrome will mark sites like this
> as
> > > > "not secure" starting very soon.
> > > >
> > > > But navigating to https://cordova.apache.org/ works as expected.
> > > >
> > > > I think the right solution is to simply redirect http://cordova.io/,
> > > > www.cordova.io, and http://cordova.apache.org/ to the https site.
> > > >
> > > > An additional point is that if I would try navigating to
> > > > https://cordova.io I I get a message that the certificate is not
> > > > valid. Should be easy to fix with help from letsencrypt.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
>
>

WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

I've done with my review with all the issues that need to resolved
with the plugin before it can be baked in to the platform for a major
version release. I'm going to discuss issues with respect to migration
of developers from UIWebView (features that will be lost or are
different)

1. Cookies don't persist. This is a WebKit bug, but someone has
created a plugin for a workaround. See
https://issues.apache.org/jira/browse/CB-12074
2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
3. Can't execute JavaScript code in the background. There are several
issues related to this. See
https://issues.apache.org/jira/browse/CB-12815
4. XmlHttpRequests don't work, because of Cross-Origin Resource
Sharing issue (CORS). There is a workaround plugin created by Oracle
(UPL licensed, which is Apache-2.0 compatible). See
https://issues.apache.org/jira/browse/CB-10143
5. Migration of localStorage from UIWebView. There is a migration
plugin available. See https://issues.apache.org/jira/browse/CB-11974

Of course there are several bugs also that need to be resolved. List
here: https://s.apache.org/QfsF

Out of the 5 issues, 3 (external) plugins are available for the
issues, 2 require minor code changes.

For a solution to issue 5, I am proposing a proxy webview engine
plugin that will:
1. Read a preference to use a particular webview engine
2. Proxy the selected webview engine's interface from its interface

This proxy will possibly help with migration and testing, so users can
"beta test" WKWebView now for existing apps (and switch back if there
are problems). This is like a "feature flag" that I mentioned before,
but at runtime, for users.

This proxy webview engine plugin can also possibly help with
InAppBrowser, I'm not sure (since that plugin has more hooks into a
webview's interface).

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

Re: [DISCUSS] Cordova-Android 7.1.1 patch release

[Shazron]

Need one more vote for Cordova-Android to wrap it up.
On Thu, Jul 12, 2018 at 7:49 PM Chris Brody  wrote:
>
> Thanks Shazron for reviewing. I just raised CB-14205
> <https://issues.apache.org/jira/browse/CB-14205> to add hints and help
> links to error messages.
>
> On Jul 12, 2018 1:57 AM, "Shazron"  wrote:
>
> I realize that and that's what I did -- the error message was not
> helpful because I thought it would just detect the one in Android
> Studio (seems to be specific to Windows?).
>
> Another gotcha: I had to add $ANDROID_HOME/emulator to my PATH to run
> it in the emulator
> On Thu, Jul 12, 2018 at 1:50 PM Darryl Pogue  wrote:
> >
> > I believe on macOS you'll need to install gradle through something
> > like Homebrew.
> >
> > On Wed, Jul 11, 2018 at 10:42 PM Shazron  wrote:
> > >
> > > Sorry, Android newbie here.
> > >
> > > I have Android 3.1.3 installed on macOS, with cordova 8.0.0.
> > > I did:
> > > cordova platform add https://github.com/apache/cordova-android#7.1.1
> > > cordova build
> > >
> > > I get this error:
> > >
> https://github.com/apache/cordova-android/blob/bf29fe0e10334938d2e6ee8116f9a30c762c40b4/bin/templates/cordova/lib/check_reqs.js#L137
> > >
> > > Should it be able to detect and use the gradle within Android
> Studio.app?
> > >
> > > Based on code inspection here, it doesn't (isWindows is false, and
> > > thus androidStudioPath is also null):
> > >
> https://github.com/apache/cordova-android/blob/bf29fe0e10334938d2e6ee8116f9a30c762c40b4/bin/templates/cordova/lib/check_reqs.js#L122
> > >
> > > I know the docs say "As of Cordova-Android 6.4.0, Gradle is now
> > > required to be installed to build Android." so perhaps the error
> > > message needs to be tweaked.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org

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

Re: https redirect needed

[Shazron]

How:
https://stackoverflow.com/a/13376283

Where:
https://svn.apache.org/repos/asf/cordova/site/public/.htaccess


On Mon, Jul 16, 2018 at 11:21 AM Shazron  wrote:
>
> I've made the redirect changes for the naked domain, as well as www subdomain.
>
> Redirecting http://c.a.o to https://c.a.o - we will have to configure
> .htaccess ourselves (there will be no foundation-wide redirects
> https://issues.apache.org/jira/browse/INFRA-15493?jql=text%20~%20%22http%20redirect%22)
>
> Regarding https://cordova.io  I'm not sure how to do this since it's
> just a 302 Redirect on the DNS level.
> On Thu, Jul 12, 2018 at 9:33 PM Chris Brody  wrote:
> >
> > If I navigate to http://cordova.io/, www.cordova.io, or
> > http://cordova.apache.org/ on Chrome (Chromium) here is what happend:
> > * it goes to http://cordova.apache.org/.
> > * I see an "i" circle in the address bar
> > * if I click it, it tells me that my connection is not secure
> >
> > It has already been announced that Chrome will mark sites like this as
> > "not secure" starting very soon.
> >
> > But navigating to https://cordova.apache.org/ works as expected.
> >
> > I think the right solution is to simply redirect http://cordova.io/,
> > www.cordova.io, and http://cordova.apache.org/ to the https site.
> >
> > An additional point is that if I would try navigating to
> > https://cordova.io I I get a message that the certificate is not
> > valid. Should be easy to fix with help from letsencrypt.org:)
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >

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

Re: Nightly build #781 for cordova has failed

[Shazron]

We control npm access. Members of the cordova npm org (which you are
part of) can create a new user token.
On Fri, Jul 13, 2018 at 4:17 PM Darryl Pogue  wrote:
>
> All npm auth tokens were revoked on Thursday following a security
> incident, so we probably need to open a ticket with infra to get a new
> token? Do we control that, or do they?
>
> On Thu, Jul 12, 2018 at 7:52 PM Apache Jenkins Server
>  wrote:
> >
> > Nightly build #781 for cordova has failed.
> >
> > Please check failure details on build details page at 
> > https://builds.apache.org/job/cordova-nightly/781/
> > You can also take a look at build console: 
> > https://builds.apache.org/job/cordova-nightly/781/consoleFull
> >
> > -
> > Jenkins for Apache Cordova
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: https redirect needed

[Shazron]

I've made the redirect changes for the naked domain, as well as www subdomain.

Redirecting http://c.a.o to https://c.a.o - we will have to configure
.htaccess ourselves (there will be no foundation-wide redirects
https://issues.apache.org/jira/browse/INFRA-15493?jql=text%20~%20%22http%20redirect%22)

Regarding https://cordova.io  I'm not sure how to do this since it's
just a 302 Redirect on the DNS level.
On Thu, Jul 12, 2018 at 9:33 PM Chris Brody  wrote:
>
> If I navigate to http://cordova.io/, www.cordova.io, or
> http://cordova.apache.org/ on Chrome (Chromium) here is what happend:
> * it goes to http://cordova.apache.org/.
> * I see an "i" circle in the address bar
> * if I click it, it tells me that my connection is not secure
>
> It has already been announced that Chrome will mark sites like this as
> "not secure" starting very soon.
>
> But navigating to https://cordova.apache.org/ works as expected.
>
> I think the right solution is to simply redirect http://cordova.io/,
> www.cordova.io, and http://cordova.apache.org/ to the https site.
>
> An additional point is that if I would try navigating to
> https://cordova.io I I get a message that the certificate is not
> valid. Should be easy to fix with help from letsencrypt.org:)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: Cordova-Android 7.1.1 patch release

[Shazron]

I vote +1:
On nodes 4, 6, 8 and 10:
- Could create a blank Android project
- Could run the Android project in Android Studio emulator
On Thu, Jul 12, 2018 at 10:15 AM Chris Brody  wrote:
>
> Please review and vote on this Cordova-Android 7.1.1 pelease by
> replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-14203
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-14203/
>
> The package was published from its corresponding git tag:
>
> cordova-android: 7.1.1 (7a97fd7e34)
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-android#7.1.1
>
> Upon a successful vote I will upload the archive to dist/, publish it
> to npm, and post the blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and
> subdependencies have Apache-compatible licenses
> * Ensured continuous build was green when repo was tagged
> * Tested on multiple Node.js versions
> * Ran automatic plugin tests from cordova-mobile-spec according to
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#1-plugin-tests-with-cordova-mobile-spec-project
> with less than 10% failure
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] Cordova-Android 7.1.1 patch release

[Shazron]

I realize that and that's what I did -- the error message was not
helpful because I thought it would just detect the one in Android
Studio (seems to be specific to Windows?).

Another gotcha: I had to add $ANDROID_HOME/emulator to my PATH to run
it in the emulator
On Thu, Jul 12, 2018 at 1:50 PM Darryl Pogue  wrote:
>
> I believe on macOS you'll need to install gradle through something
> like Homebrew.
>
> On Wed, Jul 11, 2018 at 10:42 PM Shazron  wrote:
> >
> > Sorry, Android newbie here.
> >
> > I have Android 3.1.3 installed on macOS, with cordova 8.0.0.
> > I did:
> > cordova platform add https://github.com/apache/cordova-android#7.1.1
> > cordova build
> >
> > I get this error:
> > https://github.com/apache/cordova-android/blob/bf29fe0e10334938d2e6ee8116f9a30c762c40b4/bin/templates/cordova/lib/check_reqs.js#L137
> >
> > Should it be able to detect and use the gradle within Android Studio.app?
> >
> > Based on code inspection here, it doesn't (isWindows is false, and
> > thus androidStudioPath is also null):
> > https://github.com/apache/cordova-android/blob/bf29fe0e10334938d2e6ee8116f9a30c762c40b4/bin/templates/cordova/lib/check_reqs.js#L122
> >
> > I know the docs say "As of Cordova-Android 6.4.0, Gradle is now
> > required to be installed to build Android." so perhaps the error
> > message needs to be tweaked.
> >
> > -
> > 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

[DISCUSS] Cordova-Android 7.1.1 patch release

[Shazron]

Sorry, Android newbie here.

I have Android 3.1.3 installed on macOS, with cordova 8.0.0.
I did:
cordova platform add https://github.com/apache/cordova-android#7.1.1
cordova build

I get this error:
https://github.com/apache/cordova-android/blob/bf29fe0e10334938d2e6ee8116f9a30c762c40b4/bin/templates/cordova/lib/check_reqs.js#L137

Should it be able to detect and use the gradle within Android Studio.app?

Based on code inspection here, it doesn't (isWindows is false, and
thus androidStudioPath is also null):
https://github.com/apache/cordova-android/blob/bf29fe0e10334938d2e6ee8116f9a30c762c40b4/bin/templates/cordova/lib/check_reqs.js#L122

I know the docs say "As of Cordova-Android 6.4.0, Gradle is now
required to be installed to build Android." so perhaps the error
message needs to be tweaked.

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

Re: Roadmap for next major versions

[Shazron]

Thanks Niklas,
Since you know what needs to be done or has been done with respect to
InAppBrowser - can you highlight any specific tasks or PRs that need to be
pulled in for IAB? I probably can't focus on getting anything except
WKWebView support for InAppBrowser this week (if I have the bandwidth, but
perhaps next week for a bit).

On Tue, Jul 3, 2018 at 1:30 PM Niklas Merz  wrote:

> That sounds great. Please don't forget InAppBrowser. I worked in getting
> WKwebview running in InAppBrowser a while ago and I happy to help, review
> and test these changes . Dave Alden did a good pull request on this.
>
> I flag like this sounds like a good way to test this in our app.
>
> Am 3. Juli 2018, 06:39, um 06:39, Shazron  schrieb:
> >I was thinking that the feature flag is just a convenience feature for
> >setting/removing (depends on if the flag is set/omitted):
> >
> >in
> >config.xml
> >
> >So something like this:
> >`cordova platform add ios --wkwebview` or something to that effect.
> >
> >My thinking is -- this would make manual testing easier, and remove
> >friction for testers in the interim, not to mention automated CI
> >setups. If
> >it's easier to test, perhaps more people would test it, at least that's
> >what I hope...
> >
> >Yeah the custom scheme thing, since it's iOS 11, we might have to
> >tackle
> >that once we drop iOS 10 support I suppose.
> >
> >On Tue, Jul 3, 2018 at 12:27 PM Darryl Pogue 
> >wrote:
> >
> >> Thanks Shazron!
> >>
> >> Regarding point 3 on your list, does that need to be a feature flag
> >> since the WebView engine is already controlled via a preference in
> >> config.xml? People should be able to opt-in that way just by adding a
> >> preference, and then in a future release we just change the default
> >> value for that preference, correct?
> >>
> >> From the Apple side, it sounds like they're very heavily encouraging
> >> the use of custom schemes instead of file:/// URLs for apps serving
> >> local files, but I think that wasn't introduced until iOS 11 which
> >> might be an issue for us.
> >>
> >> On Mon, Jul 2, 2018 at 8:36 PM Shazron  wrote:
> >> >
> >> > Thanks Darryl,
> >> > I'll be working on getting the WKWebView plugin up to snuff this
> >week
> >> (read
> >> > the comment thread in your doc).
> >> > 1. Review and resolve all existing PRs
> >> > 2. Integrate the WKWebView plugin into the cordova-ios repo
> >> > 3. Turn on WKWebView support via a feature flag (eventually this
> >will be
> >> > the default)
> >> >
> >> > I think no. 3 is a good way for interim testing versus having
> >long-lived
> >> > branches that might get out of sync. I don't think this will get
> >into the
> >> > same situation like `browserify` feature flag that was forgotten,
> >since
> >> we
> >> > intend to bake this in for sure.
> >> >
> >> > [CDVWebViewEngineProtocol support](
> >> >
> >>
> >
> https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h
> >> )
> >> > so we can swap in any webview engine will remain unchanged.
> >> >
> >> > On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue 
> >wrote:
> >> >
> >> > > Hi folks,
> >> > >
> >> > > As we've been discussing dropping node 4 support and how that
> >requires
> >> > > a major version bump, we should review what had already been on
> >the
> >> > > pile for next majors and what we want on the pile.
> >> > >
> >> > > I've started a Google Doc scratchpad to loosely organize
> >high-level
> >> > > goals for the various modules, and then we can start breaking
> >them
> >> > > down into JIRA tasks and putting them on the sprint boards:
> >> > >
> >> > >
> >>
> >
> https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
> >> > >
> >> > > We know that iOS 12 and Android P are both likely coming in the
> >fall,
> >> > > so it might make sense to target our release to line up around
> >that
> >> > > time and make sure we support both of the new platform versions.
> >I
> >> > > don't love the idea of waiting that long, but let's be realistic
> >about
> >> > > what we can try to achieve.
> >> > >
> >> > > ~Darryl
> >> > >
> >> > >
> >-
> >> > > 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: Roadmap for next major versions

[Shazron]

I was thinking that the feature flag is just a convenience feature for
setting/removing (depends on if the flag is set/omitted):
 in
config.xml

So something like this:
`cordova platform add ios --wkwebview` or something to that effect.

My thinking is -- this would make manual testing easier, and remove
friction for testers in the interim, not to mention automated CI setups. If
it's easier to test, perhaps more people would test it, at least that's
what I hope...

Yeah the custom scheme thing, since it's iOS 11, we might have to tackle
that once we drop iOS 10 support I suppose.

On Tue, Jul 3, 2018 at 12:27 PM Darryl Pogue  wrote:

> Thanks Shazron!
>
> Regarding point 3 on your list, does that need to be a feature flag
> since the WebView engine is already controlled via a preference in
> config.xml? People should be able to opt-in that way just by adding a
> preference, and then in a future release we just change the default
> value for that preference, correct?
>
> From the Apple side, it sounds like they're very heavily encouraging
> the use of custom schemes instead of file:/// URLs for apps serving
> local files, but I think that wasn't introduced until iOS 11 which
> might be an issue for us.
>
> On Mon, Jul 2, 2018 at 8:36 PM Shazron  wrote:
> >
> > Thanks Darryl,
> > I'll be working on getting the WKWebView plugin up to snuff this week
> (read
> > the comment thread in your doc).
> > 1. Review and resolve all existing PRs
> > 2. Integrate the WKWebView plugin into the cordova-ios repo
> > 3. Turn on WKWebView support via a feature flag (eventually this will be
> > the default)
> >
> > I think no. 3 is a good way for interim testing versus having long-lived
> > branches that might get out of sync. I don't think this will get into the
> > same situation like `browserify` feature flag that was forgotten, since
> we
> > intend to bake this in for sure.
> >
> > [CDVWebViewEngineProtocol support](
> >
> https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h
> )
> > so we can swap in any webview engine will remain unchanged.
> >
> > On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue  wrote:
> >
> > > Hi folks,
> > >
> > > As we've been discussing dropping node 4 support and how that requires
> > > a major version bump, we should review what had already been on the
> > > pile for next majors and what we want on the pile.
> > >
> > > I've started a Google Doc scratchpad to loosely organize high-level
> > > goals for the various modules, and then we can start breaking them
> > > down into JIRA tasks and putting them on the sprint boards:
> > >
> > >
> https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
> > >
> > > We know that iOS 12 and Android P are both likely coming in the fall,
> > > so it might make sense to target our release to line up around that
> > > time and make sure we support both of the new platform versions. I
> > > don't love the idea of waiting that long, but let's be realistic about
> > > what we can try to achieve.
> > >
> > > ~Darryl
> > >
> > > -
> > > 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: Roadmap for next major versions

[Shazron]

Thanks Darryl,
I'll be working on getting the WKWebView plugin up to snuff this week (read
the comment thread in your doc).
1. Review and resolve all existing PRs
2. Integrate the WKWebView plugin into the cordova-ios repo
3. Turn on WKWebView support via a feature flag (eventually this will be
the default)

I think no. 3 is a good way for interim testing versus having long-lived
branches that might get out of sync. I don't think this will get into the
same situation like `browserify` feature flag that was forgotten, since we
intend to bake this in for sure.

[CDVWebViewEngineProtocol support](
https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h)
so we can swap in any webview engine will remain unchanged.

On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue  wrote:

> Hi folks,
>
> As we've been discussing dropping node 4 support and how that requires
> a major version bump, we should review what had already been on the
> pile for next majors and what we want on the pile.
>
> I've started a Google Doc scratchpad to loosely organize high-level
> goals for the various modules, and then we can start breaking them
> down into JIRA tasks and putting them on the sprint boards:
>
> https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
>
> We know that iOS 12 and Android P are both likely coming in the fall,
> so it might make sense to target our release to line up around that
> time and make sure we support both of the new platform versions. I
> don't love the idea of waiting that long, but let's be realistic about
> what we can try to achieve.
>
> ~Darryl
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [VOTE] cordova-common@2.2.5 tools release (patch release)

[Shazron]

+1

On Sat, Jun 30, 2018 at 10:23 AM Jesse  wrote:

> I vote +1
>
> * [+] no known vulnerabilities found [440 packages audited]
> * ran tests at tagged commit 2.2.5
> * Ran coho audit-license-headers
> * Ran coho check-license
> * Ran coho verify-archive on release artifacts
> * Ensured continuous build was green when repos were tagged
>
>
>
> @purplecabbage
> risingj.com
>
> On Tue, Jun 26, 2018 at 6:57 PM, Chris Brody 
> wrote:
>
> > Please review and vote on this cordova-common 2.2.5 (patch release) by
> > replying to this email (and keep discussion on the [DISCUSS] thread)
> >
> > Release issue: https://issues.apache.org/jira/browse/CB-14174
> >
> > Purpose is to resolve npm audit issues without generating ugly engine
> > warning messages on deprecated Node.js 4 version, as needed by
> > cordova-android, cordova-ios, and additional tools and platform
> > packages.
> >
> > Artifacts for this cordova-common patch release have been published
> > to: https://dist.apache.org/repos/dist/dev/cordova/CB-14174/
> >
> > The package artifacts were published from their corresponding git tag(s):
> >
> > cordova-common: 2.2.5 (a77a1ed939)
> >
> > Upon a successful vote I will upload the archives to dist/, publish
> > them to npm, and post the corresponding blog post.
> >
> > Voting guidelines:
> >
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ran coho audit-license-headers over the 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
> >
> > Thanks and best regards,
> >
> > Chris
> >
> > https://twitter.com/brodybits
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: Stepping Back

[Shazron]

Thanks for all the years shepherding this Joe, and being the father of
PhoneGap/Cordova Android!

I'm sure it's been an interesting experience, but now it's time for someone
else to take up the mantle and be the lead for Cordova Android with your
absence. I know everyone will chip in, but ideally we would like someone to
take charge and help drive things.

It'll be a good experience for someone, taking the lead in the direction of
a major open source project.

On Fri, Jun 22, 2018 at 5:09 AM  wrote:

> Hey Joe — thanks for all your efforts over these years. Best of luck in
> your new team.
>
> Best,
> ~ Kerri
>
> Sent from my phone.
>
>
>
>
> > On Jun 20, 2018, at 14:22, Joe Bowser  wrote:
> >
> > Hey
> >
> > As many people may be aware, I've moved on to another team at Adobe, so I
> > will no longer be able to be the primary maintainer of Cordova for
> Android,
> > and I won't be available to review any PRs in the future.  It's been an
> > interesting decade of development, and I'm thankful for all the people
> who
> > chose to try and build applications with PhoneGap/Cordova, even if it
> > wasn't the right choice for them.
> >
> > Thanks
> >
> > Joe Bowser
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Android 4.4 support?

[Shazron]

"We should consider KitKat 'abandoned'" w.r.t. the media plugin, not
Cordova...

On Tue, Jun 19, 2018 at 11:47 PM Shazron  wrote:

> Using http might fix the test, for sure - but I think we should move on to
> testing https only, as the new normal.
>
> Although this is through one major browser vendor (which dwarfs all others
> at 60% market share) -- the coming https-pocalypse later this year (see
> https://techcrunch.com/2018/02/08/chrome-will-soon-mark-all-unencrypted-pages-as-not-secure/)
> is the hammer coming for most sites. These sites will not want to lose any
> Google juice and it will be the new reality (sites might not want to
> change, but customers leaving will make that choice for them).
>
> Even if we keep testing for http, most sites will eventually redirect to
> https, and we would be back to square one with the failing tests. We should
> consider KitKat 'abandoned' since Google definitely won't be updating it
> with the latest security standard.
>
> Filed and resolved: https://issues.apache.org/jira/browse/CB-14146
>
>
>
>
> On Tue, Jun 19, 2018 at 5:43 PM julio cesar sanchez <
> jcesarmob...@gmail.com> wrote:
>
>> Why don't we just use http instead of https? shouldn't that fix the
>> problems too? or https is required in other platforms?
>>
>> 2018-06-19 11:32 GMT+02:00 Ken Naito :
>>
>>> Hi Shazron,
>>>
>>> Thanks for the advice!
>>> I sent a new commit of PR, which removes some tests for Android 4.4.
>>>
>>> Ken Naito.
>>>
>>> On 2018/06/19 13:35, Shazron wrote:
>>>
>>>> Thanks Ken!
>>>> I think we should go for the simpler option, and log this as a new
>>>> issue that is known and out of our control. Android 4.4 (even though 10% of
>>>> the market) should not be a priority for us.
>>>>
>>>> On Tue, Jun 19, 2018 at 12:30 PM Ken Naito >>> k...@monaca.io>> wrote:
>>>>
>>>>
>>>> I have investigated the test failure for Android 4.4. For
>>>> cordova-plugin-media, the cause of the failure may be the SSL
>>>> handshake.
>>>>
>>>> The MediaPlayer in Android 4.4 can not connect to a modern SSL
>>>> server.
>>>> For example:
>>>> https://cordova.apache.org/downloads/BlueZedEx.mp3
>>>>
>>>> https://cordova-develop.github.io/cordova-plugin-media/res/BlueZedEx.mp3
>>>>
>>>> On the other hand, the MediaPlayer can connect to a standard SSL
>>>> server
>>>> like:
>>>> https://www.asial.co.jp/data_knaito/BlueZedEx.mp3
>>>>
>>>> I have checked the packet, and the available cipher suites of
>>>> Android
>>>> 4.4 are as follows:
>>>>
>>>> ECDHE-RSA-AES256-CBC-SHA
>>>> ECDHE-ECDSA-AES256-CBC-SHA
>>>> SRP-SHA-DSS-AES256-CBC-SHA
>>>> SRP-SHA-RSA-AES256-CBC-SHA
>>>> DHE-RSA-AES256-CBC-SHA
>>>> DHE-DSS-AES256-CBC-SHA
>>>> ECDH-RSA-AES256-CBC-SHA
>>>> ECDH-ECDSA-AES256-CBC-SHA
>>>> RSA-AES256-CBC-SHA
>>>> ECDHE-RSA-3DES-EDE-CBC-SHA
>>>> ECDHE-ECDSA-3DES-EDE-CBC-SHA
>>>> SRP-SHA-DSS-3DES-EDE-CBC-SHA
>>>> SRP-SHA-RSA-3DES-EDE-CBC-SHA
>>>> DHE-RSA-3DES-EDE-CBC-SHA
>>>> DHE-DSS-3DES-EDE-CBC-SHA
>>>> ECDH-RSA-3DES-EDE-CBC-SHA
>>>> ECDH-ECDSA-3DES-EDE-CBC-SHA
>>>> RSA-3DES-EDE-CBC-SHA
>>>> ECDHE-RSA-AES128-CBC-SHA
>>>> ECDHE-ECDSA-AES128-CBC-SHA
>>>> SRP-SHA-DSS-AES128-CBC-SHA
>>>> SRP-SHA-RSA-AES128-CBC-SHA
>>>> DHE-RSA-AES128-CBC-SHA
>>>> DHE-DSS-AES128-CBC-SHA
>>>> ECDH-RSA-AES128-CBC-SHA
>>>> ECDH-ECDSA-AES128-CBC-SHA
>>>> RSA-AES128-CBC-SHA
>>>> ECDHE-RSA-RC4-SHA
>>>> ECDHE-ECDSA-RC4-SHA
>>>> ECDH-RSA-RC4-SHA
>>>> ECDH-ECDSA-RC4-SHA
>>>> RSA-RC4-SHA
>>>> RSA-RC4-MD5
>>>>
>>>> Modern SSL servers may refuse these cipher suites.
>>>>
>>>> In order to resolve this issue, the mp3 file should be downloaded in
>>>> another way and then be played by MediaPlayer.
>>>> One way of downloading is using the okhttp library with a custom ssl
>>>> socket factory.
>>>>
>>>> However, the okhttp library is not included in the latest
>>>> cordova-android, and cordova-plugin-okhttp
>>>> (https://github.com/MobileChromeApps/cordova-plugin-okhttp) is too
>>>> old
>>>> and not maintained.
>>>>
>>>> I think that a new okhttp plugin should be created, and
>>>> cordova-plugin-media should depend on the new okhttp plugin in
>>>> order to
>>>> connect to a modern SSL server.
>>>>
>>>> Or, a more simple option is to specify that the MediaPlayer can not
>>>> connect modern SSL servers for Android 4.4, and remove the test of
>>>> playing streams for Android 4.4.
>>>>
>>>>
>>>> On 2018/06/18 13:02, Shazron wrote:
>>>> > We keep seeing this failed Media test on Android 4.4:
>>>> > https://github.com/apache/cordova-plugin-media/pull/166
>>>> >
>>>> > I'm not sure of the state of our Android support, especially
>>>> 4.4. Does
>>>> > anyone have any pointers? Thanks
>>>> >
>>>>
>>>>
>>>
>>