RE: GitHub Actions for paramedic and plugins

[Pieter Van Poyer]

Hey Tim

I am maybe a little late to the party. But this is a great effort.

It would be absolutely great to have a stable and working CI (testing) system.
Now when you submit a PR, the tests on CI are mostly red. That's annoying.

Losing ios 11.4 wouldn't be a disaster.

Kind regards

Pieter Van Poyer
1700
DI/DB

Havenbedrijf Antwerpen/Antwerp Port Authority
Zaha Hadidplein 1
2030 Antwerpen, België
T +32 3 229 76 85
pieter.vanpo...@portofantwerp.com





-Oorspronkelijk bericht-
Van: Brust, Tim 
Verzonden: donderdag 26 november 2020 15:26
Aan: dev@cordova.apache.org
Onderwerp: GitHub Actions for paramedic and plugins

Hi there,

As you might have noticed, our CI is currently red. While it's great that we do 
not block our releases because of it, it's not an ideal situation.

A short background why is broken:
We use Travis CI's virtual machines to execute our tests in combination with 
Sauce Labs, i.e., cordova-paramedic that runs on the Travis CI VM  opens a 
secure tunnel to the Sauce Labs selenium grid.
This allows for instance to test an iOS simulator on a Windows machine, as the 
simulator/emulator runs on another machine and communicates via the WebDriver 
protocol.
Sauce Labs offers real mobile devices and virtualized ones. We only use the 
latter. [1] Unfortunately, there is a network issue between the Sauce Labs and 
the Travis CI VM's, the tunnel seems established but no network requests come 
through - but not for all combos, just for some.
I've reached out to Travis CI's support and they pointed the finger to Sauce 
Labs.
Multiple attempts to have a real network engineer assigned to this task instead 
of the service level 1 assignee failed and they've just closed the ticket.

On top of this issue lies the problem with external contributions (i.e., 
outside from the Apache organization). Obviously, Sauce Labs needs some sort of 
credentials to work. We use the deprecated JWT addon at Travis [2], which might 
be disabled at any time, too.
Sadly, there is no known solution on how to securely pass the credentials to 
external forks/pull requests. There is no solution on how to make secrets 
available to forks on GitHub Actions neither.

As we are moving to GitHub Actions (or at least that's our goal), I've taken a 
look how to tackle the above problem.
Given the fact that we test simulators and emulators on Sauce Labs anyways, we 
might be able to execute everything via GitHub Actions only, i.e., no 
credentials issue.

The GitHub Actions runner have a big variety of available Xcode and iOS 
versions in their virtual environments. [3] And to have some good news - iOS 
works! [4] - the only downside is that we can't test iOS 11.4, but IMHO this 
loss would be OK.

In theory, Android works, too. With the help of the 
reactivecircus/android-emulator-runner action we can setup the emulators with a 
specific target API level. It also handles accepting the permissions etc. [5] 
At least, the logs show that the emulator booted and some things happened (like 
installing the APK)

For the browser tests, some changes in cordova-serve would be needed. In order 
to launch Chrome, Firefox etc. in headless mode, we would need to pass those 
arguments. Currently there is an open issue to add this functionality. [6]

My plan for the next week(s) is to investigate the Android timeouts and to test 
if a patch in cordova-serve would be enough to make headless launching possible 
to make the CI green.
If this works, we would have a blueprint that could be copied to the plugins. 
With the matrix syntax of GitHub Actions we can generate an easy to maintain 
and extendable testing matrix.
One feature I really like is splitting the configs in different files, as 
opposed to the gigantic .travis.yml.

Let me know what you think, I'm eager to get some feedback.
My work can be seen in the feature branch feat/gh-actions [7], especially this 
commit: [8] Cheers, Tim

[1] - 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp.saucelabs.com%2Fopen_sauce%2Fuser%2Fsnay%2Ftestsdata=04%7C01%7CPieter.VanPoyer%40portofantwerp.com%7Ca73853478c014d3b99c508d892172a68%7C2337dcc63a214d95bf72da5551a9b048%7C0%7C0%7C637419975492593209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=4n5QjT2zqfDVCOiu%2FMiz6cMsLn9LvhSBqXBBGpgMnJA%3Dreserved=0
[2] - 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.travis-ci.com%2F2018-01-23-jwt-addon-is-deprecateddata=04%7C01%7CPieter.VanPoyer%40portofantwerp.com%7Ca73853478c014d3b99c508d892172a68%7C2337dcc63a214d95bf72da5551a9b048%7C0%7C0%7C637419975492593209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5RZBQeg%2FNYeEUK4VJrLrnDyXKID1dbqMmpFYftkOOeI%3Dreserved=0
[3] - 

Re: Github Actions for issues asking for a release

[Bryan Ellis]

+1

Just need to try and make the bot smart enough to catch the requests vs 
something legit issue. I like the idea on how you have a threshold count.

Bot should also leave a good generic message as well before closing. Something 
about how we are working in various repos and do not provide set in stone ETAs. 
Also to monitor NPM for releases or mailing list to track vote threads.

Since the bot will only close and not lock threads, it give the user the 
ability to submit a reply to the thread if the bot closed inaccurately. Not 
sure if the bot should mention that though.

We already got 9 threads about Camera plugin 4.2.0 release not on NPM because 
it exists in git.

> On Jul 11, 2020, at 17:49, Niklas Merz  wrote:
> 
> Hi everyone,
> 
> I noticed quite a number issues recently that just asked for a new
> release because the tag with the new version was created for the VOTE.
> 
> As I do I thought about how to automate that. I quickly created a Github
> action [1]. It's not very smart yet but it should comment on these
> issues that we are preparing a release and follow a process.
> 
> You can test it out here [2]. What do you think?
> 
> Regards
> Niklas
> 
> [1] https://github.com/NiklasMerz/release-notify
> [2] https://github.com/NiklasMerz/release-test
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
> 


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

Re: [GitHub] [cordova-eslint] raphinesse opened a new pull request #10: feat: make base rules stricter & closer to semistandard

[raphinesse]

The configuration should be fixed by now.

Am So., 10. Nov. 2019 um 19:37 Uhr schrieb Jan Piotrowski <
piotrow...@gmail.com>:

> This repository is misconfigured, these emails should probably go to the
> commits mailing list and not dev. (Yep, the default in the infra tool is
> not optimal here)
>
> J
>
> Am Fr., 8. Nov. 2019 um 21:05 Uhr schrieb GitBox :
>
> > raphinesse opened a new pull request #10: feat: make base rules stricter
> &
> > closer to semistandard
> > URL: https://github.com/apache/cordova-eslint/pull/10
> >
> >
> >This removes all exceptions from `semistandard` we had in place,
> except
> >for `camelcase: off`. This step had already been taken in some of our
> >repos (e.g. `cordova-js`, `cordova-common`) before.
> >
> >`camelcase` stays disabled for now as enabling & enforcing it would
> have
> >the potential of creating many conflicts with existing work in
> progress.
> >
> > 
> > This is an automated message from the Apache Git Service.
> > To respond to the message, please log on to GitHub and use the
> > URL above to go to the specific comment.
> >
> > For queries about this service, please contact Infrastructure at:
> > us...@infra.apache.org
> >
> >
> > With regards,
> > Apache Git Services
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: [GitHub] [cordova-eslint] raphinesse opened a new pull request #10: feat: make base rules stricter & closer to semistandard

[Jan Piotrowski]

This repository is misconfigured, these emails should probably go to the
commits mailing list and not dev. (Yep, the default in the infra tool is
not optimal here)

J

Am Fr., 8. Nov. 2019 um 21:05 Uhr schrieb GitBox :

> raphinesse opened a new pull request #10: feat: make base rules stricter &
> closer to semistandard
> URL: https://github.com/apache/cordova-eslint/pull/10
>
>
>This removes all exceptions from `semistandard` we had in place, except
>for `camelcase: off`. This step had already been taken in some of our
>repos (e.g. `cordova-js`, `cordova-common`) before.
>
>`camelcase` stays disabled for now as enabling & enforcing it would have
>the potential of creating many conflicts with existing work in progress.
>
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> With regards,
> Apache Git Services
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: GitHub Project Board: Pull Requests

[Jan Piotrowski]

INFRA approved the use of the project-bot app [1].

It enables us to use automation on more than 5 repositories per project board.
It also adds new functionality like automatic adding of new items
(issues or PRs) to the project board, automatic moving based on
additional triggers (adding ore removing of labels, assign state,
milestone setting and much more [2]).

I am currently testing it for all active Cordova repositories at:
https://github.com/orgs/apache/projects/5?fullscreen=true

(You might notice the messages when the bot is active on issues or PRs)

If this works out, we can use it to improve our PR project boards
(less maintenance necessary) or build an issue project board (columns
by label etc.).

J

[1] https://github.com/apps/project-bot
[2] https://github.com/philschatz/project-bot#rules

2018-09-16 22:01 GMT+02:00 Jan Piotrowski :
> I had a few hours and created two additional project boards based on
> the existing project boards, this time for the plugins with the most
> PRs:
>
> https://github.com/orgs/apache/projects/9?fullscreen=true = camera,
> file, inappbrowser, media splashscreen
> https://github.com/orgs/apache/projects/10?fullscreen=true = dialogs,
> geolocation, media-capture, statusbar, whitelist
> These cover ~95% of all available plugin PRs I think.
>
> I already labeled all the PRs for the impacted platform and sorted
> them into the correct columns based on the test status (which was a
> real pain, as the plugin tests seem to fail for no reason at all or
> even all the time - we should look into this in the neat future if we
> ever want to get this under control) and if there is a conflict. There
> is no priorization of the PRs inside a column, I just dropped stuff
> into the correct one.
>
> I had also started to comment on some to get the original creator to
> fix conflicts or failing tests, but stopped after Julio mentioned it
> might not be the smartest thing to get people to do additional work on
> PRs that will never be merged. He is of course rightd. We will have to
> look at the conflicted PRs as well and close those with no chance of
> merge.
>
> Best,
> Jan
>
>
>
> 2018-09-05 16:56 GMT+02:00  :
>> Thanks again, Jan.
>>
>> Am Mi., 5. Sep. 2018 um 16:44 Uhr schrieb Jan Piotrowski <
>> piotrow...@gmail.com>:
>>
>>> > I'd rather link cordova-create than cordova-js since the latter is not
>>> > really tooling (it's kind of an outlier).
>>>
>>> Ok, changed. Makes sense.
>>>
>>> > But what's the difference between linked and unlinked repos anyway?
>>>
>>> 1. "Add Cards" has a nice "Only show results from linked repositories"
>>> checkbox which makes it easier to add those PRs to the board.
>>> 2. Automation rules are only triggered for linked repositories. So if
>>> someone merges a PR, the card/PR is only moved to the respective lane
>>> if it belongs to one of the linked repositories.
>>>
>>> No idea why GitHub had to limit this to 5.
>>> There are workarounds/tools which I will test in the near future. They
>>> are not really pretty though :/
>>>
>>> -J
>>>
>>> 2018-09-05 14:58 GMT+02:00  :
>>> > Thanks for creating this Jan!
>>> >
>>> > I'd rather link cordova-create than cordova-js since the latter is not
>>> > really tooling (it's kind of an outlier).
>>> > But what's the difference between linked and unlinked repos anyway?
>>> >
>>> > Cheers,
>>> > Raphael
>>> >
>>> > Am Mi., 5. Sep. 2018 um 12:39 Uhr schrieb Jan Piotrowski <
>>> > piotrow...@gmail.com>:
>>> >
>>> >> Having (烙/‍) in the column title turned out to be a bad idea as
>>> >> it made the messages added to PRs very noisy.
>>> >> I removed them and added a card with the same information ("column
>>> >> managed by ‍ + 烙") instead.
>>> >>
>>> >> As I personally did benefit from having the Platforms PR board in
>>> >> going through all the existing PRs, I created another one for tooling:
>>> >>
>>> >> Apache Cordova: Tooling Pull Requests
>>> >> https://github.com/orgs/apache/projects/8?fullscreen=true
>>> >> Linked repositories: cordova-js cordova-cli cordova-lib cordova-common
>>> >> cordova-fetch
>>> >>
>>> >> Unfortunately we hit the "5 linked repositories limit" here as
>>> >> predicted, and cordova-create and cordova-serve, so I had to "Add
>>> >> Cards" to them manually by searching for their PRs: `is:open is:pr
>>> >> repo:apache/cordova-serve`. Will do some research to see if there is a
>>> >>  workaround for that.
>>> >>
>>> >> Best,
>>> >> Jan
>>> >>
>>> >> 2018-09-04 11:34 GMT+02:00 Jan Piotrowski :
>>> >> > Thanks Raphael, good questions:
>>> >> >
>>> >> >> - What's the difference between: "Waiting for Review" and "Pending
>>> >> Approval"?
>>> >> >
>>> >> > Yep, that was a new thing for me as well. Let me explain:
>>> >> > "Waiting for Review" is a state we manually give to a PR after we had
>>> >> > a look and the title and description is ok, the changes make sense and
>>> >> > there are no conflicts or failing tests.
>>> >> > "Pending Approval" is a state that the automation gives to a PR 

Re: GitHub Project Board: Pull Requests

[Jan Piotrowski]

I had a few hours and created two additional project boards based on
the existing project boards, this time for the plugins with the most
PRs:

https://github.com/orgs/apache/projects/9?fullscreen=true = camera,
file, inappbrowser, media splashscreen
https://github.com/orgs/apache/projects/10?fullscreen=true = dialogs,
geolocation, media-capture, statusbar, whitelist
These cover ~95% of all available plugin PRs I think.

I already labeled all the PRs for the impacted platform and sorted
them into the correct columns based on the test status (which was a
real pain, as the plugin tests seem to fail for no reason at all or
even all the time - we should look into this in the neat future if we
ever want to get this under control) and if there is a conflict. There
is no priorization of the PRs inside a column, I just dropped stuff
into the correct one.

I had also started to comment on some to get the original creator to
fix conflicts or failing tests, but stopped after Julio mentioned it
might not be the smartest thing to get people to do additional work on
PRs that will never be merged. He is of course rightd. We will have to
look at the conflicted PRs as well and close those with no chance of
merge.

Best,
Jan



2018-09-05 16:56 GMT+02:00  :
> Thanks again, Jan.
>
> Am Mi., 5. Sep. 2018 um 16:44 Uhr schrieb Jan Piotrowski <
> piotrow...@gmail.com>:
>
>> > I'd rather link cordova-create than cordova-js since the latter is not
>> > really tooling (it's kind of an outlier).
>>
>> Ok, changed. Makes sense.
>>
>> > But what's the difference between linked and unlinked repos anyway?
>>
>> 1. "Add Cards" has a nice "Only show results from linked repositories"
>> checkbox which makes it easier to add those PRs to the board.
>> 2. Automation rules are only triggered for linked repositories. So if
>> someone merges a PR, the card/PR is only moved to the respective lane
>> if it belongs to one of the linked repositories.
>>
>> No idea why GitHub had to limit this to 5.
>> There are workarounds/tools which I will test in the near future. They
>> are not really pretty though :/
>>
>> -J
>>
>> 2018-09-05 14:58 GMT+02:00  :
>> > Thanks for creating this Jan!
>> >
>> > I'd rather link cordova-create than cordova-js since the latter is not
>> > really tooling (it's kind of an outlier).
>> > But what's the difference between linked and unlinked repos anyway?
>> >
>> > Cheers,
>> > Raphael
>> >
>> > Am Mi., 5. Sep. 2018 um 12:39 Uhr schrieb Jan Piotrowski <
>> > piotrow...@gmail.com>:
>> >
>> >> Having (烙/‍) in the column title turned out to be a bad idea as
>> >> it made the messages added to PRs very noisy.
>> >> I removed them and added a card with the same information ("column
>> >> managed by ‍ + 烙") instead.
>> >>
>> >> As I personally did benefit from having the Platforms PR board in
>> >> going through all the existing PRs, I created another one for tooling:
>> >>
>> >> Apache Cordova: Tooling Pull Requests
>> >> https://github.com/orgs/apache/projects/8?fullscreen=true
>> >> Linked repositories: cordova-js cordova-cli cordova-lib cordova-common
>> >> cordova-fetch
>> >>
>> >> Unfortunately we hit the "5 linked repositories limit" here as
>> >> predicted, and cordova-create and cordova-serve, so I had to "Add
>> >> Cards" to them manually by searching for their PRs: `is:open is:pr
>> >> repo:apache/cordova-serve`. Will do some research to see if there is a
>> >>  workaround for that.
>> >>
>> >> Best,
>> >> Jan
>> >>
>> >> 2018-09-04 11:34 GMT+02:00 Jan Piotrowski :
>> >> > Thanks Raphael, good questions:
>> >> >
>> >> >> - What's the difference between: "Waiting for Review" and "Pending
>> >> Approval"?
>> >> >
>> >> > Yep, that was a new thing for me as well. Let me explain:
>> >> > "Waiting for Review" is a state we manually give to a PR after we had
>> >> > a look and the title and description is ok, the changes make sense and
>> >> > there are no conflicts or failing tests.
>> >> > "Pending Approval" is a state that the automation gives to a PR when
>> >> > there was some review activity (e.g. "comment" or "request changes")
>> >> > but the PR is not _approved_ (yet).
>> >> > This also applies in the case that the repo has a "3 approvals before
>> >> > merge" requirement for example, then a PR with 1 approval would move
>> >> > to that column.
>> >> > Maybe also if someone leaves a review who is not a maintainer - but I
>> >> > am not 100% sure about that.
>> >> > One could also call the column "Review in progress" maybe - but I
>> >> > wanted to see it in practice first to be honest.
>> >> >
>> >> >> - Do we need to distinguish "Blocked: Tests failing" and "Blocked:
>> >> Conflict"?
>> >> >
>> >> > We don't need to, but I thought it might be handy.
>> >> > A PR in the "tests failing" can be moved to "waiting for review" when
>> >> > there is not red x any more that indicates a failing test (because
>> >> > there was a new commit or tests were rerun). For conflicts, there is
>> >> > no visual indicator and 

Re: GitHub Project Board: Pull Requests

[raphinesse]

Thanks again, Jan.

Am Mi., 5. Sep. 2018 um 16:44 Uhr schrieb Jan Piotrowski <
piotrow...@gmail.com>:

> > I'd rather link cordova-create than cordova-js since the latter is not
> > really tooling (it's kind of an outlier).
>
> Ok, changed. Makes sense.
>
> > But what's the difference between linked and unlinked repos anyway?
>
> 1. "Add Cards" has a nice "Only show results from linked repositories"
> checkbox which makes it easier to add those PRs to the board.
> 2. Automation rules are only triggered for linked repositories. So if
> someone merges a PR, the card/PR is only moved to the respective lane
> if it belongs to one of the linked repositories.
>
> No idea why GitHub had to limit this to 5.
> There are workarounds/tools which I will test in the near future. They
> are not really pretty though :/
>
> -J
>
> 2018-09-05 14:58 GMT+02:00  :
> > Thanks for creating this Jan!
> >
> > I'd rather link cordova-create than cordova-js since the latter is not
> > really tooling (it's kind of an outlier).
> > But what's the difference between linked and unlinked repos anyway?
> >
> > Cheers,
> > Raphael
> >
> > Am Mi., 5. Sep. 2018 um 12:39 Uhr schrieb Jan Piotrowski <
> > piotrow...@gmail.com>:
> >
> >> Having (烙/‍) in the column title turned out to be a bad idea as
> >> it made the messages added to PRs very noisy.
> >> I removed them and added a card with the same information ("column
> >> managed by ‍ + 烙") instead.
> >>
> >> As I personally did benefit from having the Platforms PR board in
> >> going through all the existing PRs, I created another one for tooling:
> >>
> >> Apache Cordova: Tooling Pull Requests
> >> https://github.com/orgs/apache/projects/8?fullscreen=true
> >> Linked repositories: cordova-js cordova-cli cordova-lib cordova-common
> >> cordova-fetch
> >>
> >> Unfortunately we hit the "5 linked repositories limit" here as
> >> predicted, and cordova-create and cordova-serve, so I had to "Add
> >> Cards" to them manually by searching for their PRs: `is:open is:pr
> >> repo:apache/cordova-serve`. Will do some research to see if there is a
> >>  workaround for that.
> >>
> >> Best,
> >> Jan
> >>
> >> 2018-09-04 11:34 GMT+02:00 Jan Piotrowski :
> >> > Thanks Raphael, good questions:
> >> >
> >> >> - What's the difference between: "Waiting for Review" and "Pending
> >> Approval"?
> >> >
> >> > Yep, that was a new thing for me as well. Let me explain:
> >> > "Waiting for Review" is a state we manually give to a PR after we had
> >> > a look and the title and description is ok, the changes make sense and
> >> > there are no conflicts or failing tests.
> >> > "Pending Approval" is a state that the automation gives to a PR when
> >> > there was some review activity (e.g. "comment" or "request changes")
> >> > but the PR is not _approved_ (yet).
> >> > This also applies in the case that the repo has a "3 approvals before
> >> > merge" requirement for example, then a PR with 1 approval would move
> >> > to that column.
> >> > Maybe also if someone leaves a review who is not a maintainer - but I
> >> > am not 100% sure about that.
> >> > One could also call the column "Review in progress" maybe - but I
> >> > wanted to see it in practice first to be honest.
> >> >
> >> >> - Do we need to distinguish "Blocked: Tests failing" and "Blocked:
> >> Conflict"?
> >> >
> >> > We don't need to, but I thought it might be handy.
> >> > A PR in the "tests failing" can be moved to "waiting for review" when
> >> > there is not red x any more that indicates a failing test (because
> >> > there was a new commit or tests were rerun). For conflicts, there is
> >> > no visual indicator and the PR _has_ to be checked manually.
> >> > If there is not much use for that, we can collapse both columns into
> >> > one without much effort. But for now I would leave it as it is to get
> >> > some experience with it.
> >> >
> >> > Best,
> >> > Jan
> >> >
> >> >
> >> >
> >> > 2018-09-03 18:16 GMT+02:00 gandhi rajan :
> >> >> Looks great Jan. But for some reason I m not able to see the emojis
> in
> >> my
> >> >> chrome browser. Does anyone else have the same issue?
> >> >>
> >> >> On Mon, Sep 3, 2018 at 6:13 PM Jan Piotrowski 
> >> wrote:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> with the switch to GitHub for issues I started looking into GitHub
> >> >>> Project boards to help us manage Issues and Pull Requests.
> >> >>>
> >> >>> The first concrete result of this is ready for feedback:
> >> >>>
> >> >>> Apache Cordova - Platforms Pull Requests
> >> >>> https://github.com/orgs/apache/projects/7
> >> >>>
> >> >>> As the name implies, this board contains all Pull Requests for the
> >> >>> Platform repositories (ios, android, windows, osx, browser). It can
> be
> >> >>> used to 1) get an overview of all the PRs for several repositories
> at
> >> >>> the same time and 2) help us maintainers to find PRs to comment on,
> >> >>> test and approve or merge.
> >> >>>
> >> >>> The project board contains these columns:
> >> >>>
> >> >>> -  

Re: GitHub Project Board: Pull Requests

[Jan Piotrowski]

> I'd rather link cordova-create than cordova-js since the latter is not
> really tooling (it's kind of an outlier).

Ok, changed. Makes sense.

> But what's the difference between linked and unlinked repos anyway?

1. "Add Cards" has a nice "Only show results from linked repositories"
checkbox which makes it easier to add those PRs to the board.
2. Automation rules are only triggered for linked repositories. So if
someone merges a PR, the card/PR is only moved to the respective lane
if it belongs to one of the linked repositories.

No idea why GitHub had to limit this to 5.
There are workarounds/tools which I will test in the near future. They
are not really pretty though :/

-J

2018-09-05 14:58 GMT+02:00  :
> Thanks for creating this Jan!
>
> I'd rather link cordova-create than cordova-js since the latter is not
> really tooling (it's kind of an outlier).
> But what's the difference between linked and unlinked repos anyway?
>
> Cheers,
> Raphael
>
> Am Mi., 5. Sep. 2018 um 12:39 Uhr schrieb Jan Piotrowski <
> piotrow...@gmail.com>:
>
>> Having (烙/‍) in the column title turned out to be a bad idea as
>> it made the messages added to PRs very noisy.
>> I removed them and added a card with the same information ("column
>> managed by ‍ + 烙") instead.
>>
>> As I personally did benefit from having the Platforms PR board in
>> going through all the existing PRs, I created another one for tooling:
>>
>> Apache Cordova: Tooling Pull Requests
>> https://github.com/orgs/apache/projects/8?fullscreen=true
>> Linked repositories: cordova-js cordova-cli cordova-lib cordova-common
>> cordova-fetch
>>
>> Unfortunately we hit the "5 linked repositories limit" here as
>> predicted, and cordova-create and cordova-serve, so I had to "Add
>> Cards" to them manually by searching for their PRs: `is:open is:pr
>> repo:apache/cordova-serve`. Will do some research to see if there is a
>>  workaround for that.
>>
>> Best,
>> Jan
>>
>> 2018-09-04 11:34 GMT+02:00 Jan Piotrowski :
>> > Thanks Raphael, good questions:
>> >
>> >> - What's the difference between: "Waiting for Review" and "Pending
>> Approval"?
>> >
>> > Yep, that was a new thing for me as well. Let me explain:
>> > "Waiting for Review" is a state we manually give to a PR after we had
>> > a look and the title and description is ok, the changes make sense and
>> > there are no conflicts or failing tests.
>> > "Pending Approval" is a state that the automation gives to a PR when
>> > there was some review activity (e.g. "comment" or "request changes")
>> > but the PR is not _approved_ (yet).
>> > This also applies in the case that the repo has a "3 approvals before
>> > merge" requirement for example, then a PR with 1 approval would move
>> > to that column.
>> > Maybe also if someone leaves a review who is not a maintainer - but I
>> > am not 100% sure about that.
>> > One could also call the column "Review in progress" maybe - but I
>> > wanted to see it in practice first to be honest.
>> >
>> >> - Do we need to distinguish "Blocked: Tests failing" and "Blocked:
>> Conflict"?
>> >
>> > We don't need to, but I thought it might be handy.
>> > A PR in the "tests failing" can be moved to "waiting for review" when
>> > there is not red x any more that indicates a failing test (because
>> > there was a new commit or tests were rerun). For conflicts, there is
>> > no visual indicator and the PR _has_ to be checked manually.
>> > If there is not much use for that, we can collapse both columns into
>> > one without much effort. But for now I would leave it as it is to get
>> > some experience with it.
>> >
>> > Best,
>> > Jan
>> >
>> >
>> >
>> > 2018-09-03 18:16 GMT+02:00 gandhi rajan :
>> >> Looks great Jan. But for some reason I m not able to see the emojis in
>> my
>> >> chrome browser. Does anyone else have the same issue?
>> >>
>> >> On Mon, Sep 3, 2018 at 6:13 PM Jan Piotrowski 
>> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> with the switch to GitHub for issues I started looking into GitHub
>> >>> Project boards to help us manage Issues and Pull Requests.
>> >>>
>> >>> The first concrete result of this is ready for feedback:
>> >>>
>> >>> Apache Cordova - Platforms Pull Requests
>> >>> https://github.com/orgs/apache/projects/7
>> >>>
>> >>> As the name implies, this board contains all Pull Requests for the
>> >>> Platform repositories (ios, android, windows, osx, browser). It can be
>> >>> used to 1) get an overview of all the PRs for several repositories at
>> >>> the same time and 2) help us maintainers to find PRs to comment on,
>> >>> test and approve or merge.
>> >>>
>> >>> The project board contains these columns:
>> >>>
>> >>> -  New PR / Untriaged (烙/‍)
>> >>> -  Blocked: Work in Progress (‍)
>> >>> - ⛔ Blocked: Tests failing (‍)
>> >>> -  Blocked: Conflict (‍)
>> >>> - ⏳ Waiting for Review (‍)
>> >>> -  Pending Approval (烙)
>> >>> - ✅ Approved, waiting for Merge (烙)
>> >>> -  Merged, waiting for Release (烙)
>> >>> - ☠️ Closed/Abandoned (烙)
>> >>> -  

Re: GitHub Project Board: Pull Requests

[raphinesse]

Thanks for creating this Jan!

I'd rather link cordova-create than cordova-js since the latter is not
really tooling (it's kind of an outlier).
But what's the difference between linked and unlinked repos anyway?

Cheers,
Raphael

Am Mi., 5. Sep. 2018 um 12:39 Uhr schrieb Jan Piotrowski <
piotrow...@gmail.com>:

> Having (烙/‍) in the column title turned out to be a bad idea as
> it made the messages added to PRs very noisy.
> I removed them and added a card with the same information ("column
> managed by ‍ + 烙") instead.
>
> As I personally did benefit from having the Platforms PR board in
> going through all the existing PRs, I created another one for tooling:
>
> Apache Cordova: Tooling Pull Requests
> https://github.com/orgs/apache/projects/8?fullscreen=true
> Linked repositories: cordova-js cordova-cli cordova-lib cordova-common
> cordova-fetch
>
> Unfortunately we hit the "5 linked repositories limit" here as
> predicted, and cordova-create and cordova-serve, so I had to "Add
> Cards" to them manually by searching for their PRs: `is:open is:pr
> repo:apache/cordova-serve`. Will do some research to see if there is a
>  workaround for that.
>
> Best,
> Jan
>
> 2018-09-04 11:34 GMT+02:00 Jan Piotrowski :
> > Thanks Raphael, good questions:
> >
> >> - What's the difference between: "Waiting for Review" and "Pending
> Approval"?
> >
> > Yep, that was a new thing for me as well. Let me explain:
> > "Waiting for Review" is a state we manually give to a PR after we had
> > a look and the title and description is ok, the changes make sense and
> > there are no conflicts or failing tests.
> > "Pending Approval" is a state that the automation gives to a PR when
> > there was some review activity (e.g. "comment" or "request changes")
> > but the PR is not _approved_ (yet).
> > This also applies in the case that the repo has a "3 approvals before
> > merge" requirement for example, then a PR with 1 approval would move
> > to that column.
> > Maybe also if someone leaves a review who is not a maintainer - but I
> > am not 100% sure about that.
> > One could also call the column "Review in progress" maybe - but I
> > wanted to see it in practice first to be honest.
> >
> >> - Do we need to distinguish "Blocked: Tests failing" and "Blocked:
> Conflict"?
> >
> > We don't need to, but I thought it might be handy.
> > A PR in the "tests failing" can be moved to "waiting for review" when
> > there is not red x any more that indicates a failing test (because
> > there was a new commit or tests were rerun). For conflicts, there is
> > no visual indicator and the PR _has_ to be checked manually.
> > If there is not much use for that, we can collapse both columns into
> > one without much effort. But for now I would leave it as it is to get
> > some experience with it.
> >
> > Best,
> > Jan
> >
> >
> >
> > 2018-09-03 18:16 GMT+02:00 gandhi rajan :
> >> Looks great Jan. But for some reason I m not able to see the emojis in
> my
> >> chrome browser. Does anyone else have the same issue?
> >>
> >> On Mon, Sep 3, 2018 at 6:13 PM Jan Piotrowski 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> with the switch to GitHub for issues I started looking into GitHub
> >>> Project boards to help us manage Issues and Pull Requests.
> >>>
> >>> The first concrete result of this is ready for feedback:
> >>>
> >>> Apache Cordova - Platforms Pull Requests
> >>> https://github.com/orgs/apache/projects/7
> >>>
> >>> As the name implies, this board contains all Pull Requests for the
> >>> Platform repositories (ios, android, windows, osx, browser). It can be
> >>> used to 1) get an overview of all the PRs for several repositories at
> >>> the same time and 2) help us maintainers to find PRs to comment on,
> >>> test and approve or merge.
> >>>
> >>> The project board contains these columns:
> >>>
> >>> -  New PR / Untriaged (烙/‍)
> >>> -  Blocked: Work in Progress (‍)
> >>> - ⛔ Blocked: Tests failing (‍)
> >>> -  Blocked: Conflict (‍)
> >>> - ⏳ Waiting for Review (‍)
> >>> -  Pending Approval (烙)
> >>> - ✅ Approved, waiting for Merge (烙)
> >>> -  Merged, waiting for Release (烙)
> >>> - ☠️ Closed/Abandoned (烙)
> >>> -  Released (‍)
> >>>
> >>> The columns itself should cover all the common cases we can encounter
> >>> with PRs (Did I miss anything that should be tracked?).
> >>>
> >>> The column a PR is currently located in is shown in the "Projects"
> >>> section of the sidebar of the PR on GitHub. Each time a PR is moved,
> >>> the PR gets a " moved this from  to " line added
> >>> at the bottom. The emojis make parsing these info bits a lot easier.
> >>>
> >>> New PRs can be added to this board a) semi-automatically by clicking
> >>> the "Cog" icon next to "Projects" in the sidebar of a PR on Github and
> >>> then selecting the board or b) by using the "Add cards" functionality
> >>> on the board itself. There is no way to fully automatically add new
> >>> PRs to this board yet [1].
> >>>
> >>> The emojis at the end of the column 

Re: GitHub Project Board: Pull Requests

[Jan Piotrowski]

Having (烙/‍) in the column title turned out to be a bad idea as
it made the messages added to PRs very noisy.
I removed them and added a card with the same information ("column
managed by ‍ + 烙") instead.

As I personally did benefit from having the Platforms PR board in
going through all the existing PRs, I created another one for tooling:

Apache Cordova: Tooling Pull Requests
https://github.com/orgs/apache/projects/8?fullscreen=true
Linked repositories: cordova-js cordova-cli cordova-lib cordova-common
cordova-fetch

Unfortunately we hit the "5 linked repositories limit" here as
predicted, and cordova-create and cordova-serve, so I had to "Add
Cards" to them manually by searching for their PRs: `is:open is:pr
repo:apache/cordova-serve`. Will do some research to see if there is a
 workaround for that.

Best,
Jan

2018-09-04 11:34 GMT+02:00 Jan Piotrowski :
> Thanks Raphael, good questions:
>
>> - What's the difference between: "Waiting for Review" and "Pending Approval"?
>
> Yep, that was a new thing for me as well. Let me explain:
> "Waiting for Review" is a state we manually give to a PR after we had
> a look and the title and description is ok, the changes make sense and
> there are no conflicts or failing tests.
> "Pending Approval" is a state that the automation gives to a PR when
> there was some review activity (e.g. "comment" or "request changes")
> but the PR is not _approved_ (yet).
> This also applies in the case that the repo has a "3 approvals before
> merge" requirement for example, then a PR with 1 approval would move
> to that column.
> Maybe also if someone leaves a review who is not a maintainer - but I
> am not 100% sure about that.
> One could also call the column "Review in progress" maybe - but I
> wanted to see it in practice first to be honest.
>
>> - Do we need to distinguish "Blocked: Tests failing" and "Blocked: Conflict"?
>
> We don't need to, but I thought it might be handy.
> A PR in the "tests failing" can be moved to "waiting for review" when
> there is not red x any more that indicates a failing test (because
> there was a new commit or tests were rerun). For conflicts, there is
> no visual indicator and the PR _has_ to be checked manually.
> If there is not much use for that, we can collapse both columns into
> one without much effort. But for now I would leave it as it is to get
> some experience with it.
>
> Best,
> Jan
>
>
>
> 2018-09-03 18:16 GMT+02:00 gandhi rajan :
>> Looks great Jan. But for some reason I m not able to see the emojis in my
>> chrome browser. Does anyone else have the same issue?
>>
>> On Mon, Sep 3, 2018 at 6:13 PM Jan Piotrowski  wrote:
>>
>>> Hi,
>>>
>>> with the switch to GitHub for issues I started looking into GitHub
>>> Project boards to help us manage Issues and Pull Requests.
>>>
>>> The first concrete result of this is ready for feedback:
>>>
>>> Apache Cordova - Platforms Pull Requests
>>> https://github.com/orgs/apache/projects/7
>>>
>>> As the name implies, this board contains all Pull Requests for the
>>> Platform repositories (ios, android, windows, osx, browser). It can be
>>> used to 1) get an overview of all the PRs for several repositories at
>>> the same time and 2) help us maintainers to find PRs to comment on,
>>> test and approve or merge.
>>>
>>> The project board contains these columns:
>>>
>>> -  New PR / Untriaged (烙/‍)
>>> -  Blocked: Work in Progress (‍)
>>> - ⛔ Blocked: Tests failing (‍)
>>> -  Blocked: Conflict (‍)
>>> - ⏳ Waiting for Review (‍)
>>> -  Pending Approval (烙)
>>> - ✅ Approved, waiting for Merge (烙)
>>> -  Merged, waiting for Release (烙)
>>> - ☠️ Closed/Abandoned (烙)
>>> -  Released (‍)
>>>
>>> The columns itself should cover all the common cases we can encounter
>>> with PRs (Did I miss anything that should be tracked?).
>>>
>>> The column a PR is currently located in is shown in the "Projects"
>>> section of the sidebar of the PR on GitHub. Each time a PR is moved,
>>> the PR gets a " moved this from  to " line added
>>> at the bottom. The emojis make parsing these info bits a lot easier.
>>>
>>> New PRs can be added to this board a) semi-automatically by clicking
>>> the "Cog" icon next to "Projects" in the sidebar of a PR on Github and
>>> then selecting the board or b) by using the "Add cards" functionality
>>> on the board itself. There is no way to fully automatically add new
>>> PRs to this board yet [1].
>>>
>>> The emojis at the end of the column description (烙/‍) explain who
>>> is responsible for getting PRs into or out of a lane. As you can see
>>> only the first 5 columns (and the last one) have to be handled
>>> manually, the rest is automated.
>>> Our "work" on this board is only to get all PRs from "New PR" to
>>> "Waiting for Review" in the board. Then the automation takes over by
>>> looking if a PR is approved, merged or closed on GitHub itself. At the
>>> end we can manually track what PRs were released to users.
>>>
>>>
>>> Feedback or Comments?
>>>
>>> If 

Re: GitHub Project Board: Pull Requests

[Jan Piotrowski]

Thanks Raphael, good questions:

> - What's the difference between: "Waiting for Review" and "Pending Approval"?

Yep, that was a new thing for me as well. Let me explain:
"Waiting for Review" is a state we manually give to a PR after we had
a look and the title and description is ok, the changes make sense and
there are no conflicts or failing tests.
"Pending Approval" is a state that the automation gives to a PR when
there was some review activity (e.g. "comment" or "request changes")
but the PR is not _approved_ (yet).
This also applies in the case that the repo has a "3 approvals before
merge" requirement for example, then a PR with 1 approval would move
to that column.
Maybe also if someone leaves a review who is not a maintainer - but I
am not 100% sure about that.
One could also call the column "Review in progress" maybe - but I
wanted to see it in practice first to be honest.

> - Do we need to distinguish "Blocked: Tests failing" and "Blocked: Conflict"?

We don't need to, but I thought it might be handy.
A PR in the "tests failing" can be moved to "waiting for review" when
there is not red x any more that indicates a failing test (because
there was a new commit or tests were rerun). For conflicts, there is
no visual indicator and the PR _has_ to be checked manually.
If there is not much use for that, we can collapse both columns into
one without much effort. But for now I would leave it as it is to get
some experience with it.

Best,
Jan



2018-09-03 18:16 GMT+02:00 gandhi rajan :
> Looks great Jan. But for some reason I m not able to see the emojis in my
> chrome browser. Does anyone else have the same issue?
>
> On Mon, Sep 3, 2018 at 6:13 PM Jan Piotrowski  wrote:
>
>> Hi,
>>
>> with the switch to GitHub for issues I started looking into GitHub
>> Project boards to help us manage Issues and Pull Requests.
>>
>> The first concrete result of this is ready for feedback:
>>
>> Apache Cordova - Platforms Pull Requests
>> https://github.com/orgs/apache/projects/7
>>
>> As the name implies, this board contains all Pull Requests for the
>> Platform repositories (ios, android, windows, osx, browser). It can be
>> used to 1) get an overview of all the PRs for several repositories at
>> the same time and 2) help us maintainers to find PRs to comment on,
>> test and approve or merge.
>>
>> The project board contains these columns:
>>
>> -  New PR / Untriaged (烙/‍)
>> -  Blocked: Work in Progress (‍)
>> - ⛔ Blocked: Tests failing (‍)
>> -  Blocked: Conflict (‍)
>> - ⏳ Waiting for Review (‍)
>> -  Pending Approval (烙)
>> - ✅ Approved, waiting for Merge (烙)
>> -  Merged, waiting for Release (烙)
>> - ☠️ Closed/Abandoned (烙)
>> -  Released (‍)
>>
>> The columns itself should cover all the common cases we can encounter
>> with PRs (Did I miss anything that should be tracked?).
>>
>> The column a PR is currently located in is shown in the "Projects"
>> section of the sidebar of the PR on GitHub. Each time a PR is moved,
>> the PR gets a " moved this from  to " line added
>> at the bottom. The emojis make parsing these info bits a lot easier.
>>
>> New PRs can be added to this board a) semi-automatically by clicking
>> the "Cog" icon next to "Projects" in the sidebar of a PR on Github and
>> then selecting the board or b) by using the "Add cards" functionality
>> on the board itself. There is no way to fully automatically add new
>> PRs to this board yet [1].
>>
>> The emojis at the end of the column description (烙/‍) explain who
>> is responsible for getting PRs into or out of a lane. As you can see
>> only the first 5 columns (and the last one) have to be handled
>> manually, the rest is automated.
>> Our "work" on this board is only to get all PRs from "New PR" to
>> "Waiting for Review" in the board. Then the automation takes over by
>> looking if a PR is approved, merged or closed on GitHub itself. At the
>> end we can manually track what PRs were released to users.
>>
>>
>> Feedback or Comments?
>>
>> If this is welcome, I will create identical project boards for tooling
>> and plugins. [2]
>>
>> Best,
>> Jan
>>
>>
>>
>> [1] If this project board is considered useful and will be used, there
>> are options to automatically add new PRs to this column via GitHub
>> apps. We certainly could use this, but I didn't want to spend the time
>> to configure this up front.
>>
>> [2] It will be interesting to see how the automation will work for
>> e.g. Plugins where we have >5 repositories. Probably we will also need
>> a workaround the "5 repo per project board" limit from Github via an
>> GitHub app.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>
>
> --
> Regards,
> Gandhi
>
> "The best way to find urself is to lose urself in the service of others !!!"

-
To 

Re: GitHub Project Board: Pull Requests

[gandhi rajan]

Looks great Jan. But for some reason I m not able to see the emojis in my
chrome browser. Does anyone else have the same issue?

On Mon, Sep 3, 2018 at 6:13 PM Jan Piotrowski  wrote:

> Hi,
>
> with the switch to GitHub for issues I started looking into GitHub
> Project boards to help us manage Issues and Pull Requests.
>
> The first concrete result of this is ready for feedback:
>
> Apache Cordova - Platforms Pull Requests
> https://github.com/orgs/apache/projects/7
>
> As the name implies, this board contains all Pull Requests for the
> Platform repositories (ios, android, windows, osx, browser). It can be
> used to 1) get an overview of all the PRs for several repositories at
> the same time and 2) help us maintainers to find PRs to comment on,
> test and approve or merge.
>
> The project board contains these columns:
>
> -  New PR / Untriaged (烙/‍)
> -  Blocked: Work in Progress (‍)
> - ⛔ Blocked: Tests failing (‍)
> -  Blocked: Conflict (‍)
> - ⏳ Waiting for Review (‍)
> -  Pending Approval (烙)
> - ✅ Approved, waiting for Merge (烙)
> -  Merged, waiting for Release (烙)
> - ☠️ Closed/Abandoned (烙)
> -  Released (‍)
>
> The columns itself should cover all the common cases we can encounter
> with PRs (Did I miss anything that should be tracked?).
>
> The column a PR is currently located in is shown in the "Projects"
> section of the sidebar of the PR on GitHub. Each time a PR is moved,
> the PR gets a " moved this from  to " line added
> at the bottom. The emojis make parsing these info bits a lot easier.
>
> New PRs can be added to this board a) semi-automatically by clicking
> the "Cog" icon next to "Projects" in the sidebar of a PR on Github and
> then selecting the board or b) by using the "Add cards" functionality
> on the board itself. There is no way to fully automatically add new
> PRs to this board yet [1].
>
> The emojis at the end of the column description (烙/‍) explain who
> is responsible for getting PRs into or out of a lane. As you can see
> only the first 5 columns (and the last one) have to be handled
> manually, the rest is automated.
> Our "work" on this board is only to get all PRs from "New PR" to
> "Waiting for Review" in the board. Then the automation takes over by
> looking if a PR is approved, merged or closed on GitHub itself. At the
> end we can manually track what PRs were released to users.
>
>
> Feedback or Comments?
>
> If this is welcome, I will create identical project boards for tooling
> and plugins. [2]
>
> Best,
> Jan
>
>
>
> [1] If this project board is considered useful and will be used, there
> are options to automatically add new PRs to this column via GitHub
> apps. We certainly could use this, but I didn't want to spend the time
> to configure this up front.
>
> [2] It will be interesting to see how the automation will work for
> e.g. Plugins where we have >5 repositories. Probably we will also need
> a workaround the "5 repo per project board" limit from Github via an
> GitHub app.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

-- 
Regards,
Gandhi

"The best way to find urself is to lose urself in the service of others !!!"

Re: GitHub Project Board: Pull Requests

[raphinesse]

Looks very nice. Great work Jan!

Two questions:
- What's the difference between: "Waiting for Review" and "Pending
Approval"?
- Do we need to distinguish "Blocked: Tests failing" and "Blocked:
Conflict"?

Cheers,
Raphael

Am Mo., 3. Sep. 2018 um 14:43 Uhr schrieb Jan Piotrowski <
piotrow...@gmail.com>:

> Hi,
>
> with the switch to GitHub for issues I started looking into GitHub
> Project boards to help us manage Issues and Pull Requests.
>
> The first concrete result of this is ready for feedback:
>
> Apache Cordova - Platforms Pull Requests
> https://github.com/orgs/apache/projects/7
>
> As the name implies, this board contains all Pull Requests for the
> Platform repositories (ios, android, windows, osx, browser). It can be
> used to 1) get an overview of all the PRs for several repositories at
> the same time and 2) help us maintainers to find PRs to comment on,
> test and approve or merge.
>
> The project board contains these columns:
>
> -  New PR / Untriaged (烙/‍)
> -  Blocked: Work in Progress (‍)
> - ⛔ Blocked: Tests failing (‍)
> -  Blocked: Conflict (‍)
> - ⏳ Waiting for Review (‍)
> -  Pending Approval (烙)
> - ✅ Approved, waiting for Merge (烙)
> -  Merged, waiting for Release (烙)
> - ☠️ Closed/Abandoned (烙)
> -  Released (‍)
>
> The columns itself should cover all the common cases we can encounter
> with PRs (Did I miss anything that should be tracked?).
>
> The column a PR is currently located in is shown in the "Projects"
> section of the sidebar of the PR on GitHub. Each time a PR is moved,
> the PR gets a " moved this from  to " line added
> at the bottom. The emojis make parsing these info bits a lot easier.
>
> New PRs can be added to this board a) semi-automatically by clicking
> the "Cog" icon next to "Projects" in the sidebar of a PR on Github and
> then selecting the board or b) by using the "Add cards" functionality
> on the board itself. There is no way to fully automatically add new
> PRs to this board yet [1].
>
> The emojis at the end of the column description (烙/‍) explain who
> is responsible for getting PRs into or out of a lane. As you can see
> only the first 5 columns (and the last one) have to be handled
> manually, the rest is automated.
> Our "work" on this board is only to get all PRs from "New PR" to
> "Waiting for Review" in the board. Then the automation takes over by
> looking if a PR is approved, merged or closed on GitHub itself. At the
> end we can manually track what PRs were released to users.
>
>
> Feedback or Comments?
>
> If this is welcome, I will create identical project boards for tooling
> and plugins. [2]
>
> Best,
> Jan
>
>
>
> [1] If this project board is considered useful and will be used, there
> are options to automatically add new PRs to this column via GitHub
> apps. We certainly could use this, but I didn't want to spend the time
> to configure this up front.
>
> [2] It will be interesting to see how the automation will work for
> e.g. Plugins where we have >5 repositories. Probably we will also need
> a workaround the "5 repo per project board" limit from Github via an
> GitHub app.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [GitHub] janpio opened a new issue #2: TEst

[Jan Piotrowski]

Seems apache/cordova is misconfiged, I created an INFRA issue to
change the notification email from dev@ to commits@:
https://issues.apache.org/jira/browse/INFRA-16945
Am Do., 23. Aug. 2018 um 11:11 Uhr schrieb GitBox :
>
> janpio opened a new issue #2: TEst
> URL: https://github.com/apache/cordova/issues/2
>
>
>_From @janpio on August 23, 2018 9:11_
>
>test
>
>_Copied from original issue: apache/cordova-discuss#109_
>
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> With regards,
> Apache Git Services
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [GitHub] janpio opened a new pull request #1: [WIP] Deprecation and Archiving Policy

[Jan Piotrowski]

Sorry for this email, I seem to have misconfigured the new repo. Will
get it changed by INFRA.

J
Am Mi., 22. Aug. 2018 um 19:18 Uhr schrieb GitBox :
>
> janpio opened a new pull request #1: [WIP] Deprecation and Archiving Policy
> URL: https://github.com/apache/cordova-contribute/pull/1
>
>
>Work in Progress PR - will send out email to dev mailing list when read to 
> review (and change title and this description)
>
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> With regards,
> Apache Git Services
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [GitHub] cordova-lib issue #558: CB-12766 Consistently write JSON with 2 spaces inden...,

[Giorgio Natili]

,,

On Tue, May 16, 2017 at 12:20 PM stevengill  wrote:

> Github user stevengill commented on the issue:
>
> https://github.com/apache/cordova-lib/pull/558
>
> really good point. We should switch to two like npm.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
> --
Sorry for the brevity, Sent from Gmail Mobile

Re: [GITHUB MOVE] Bulk move of all repos

[Shazron]

Closed the other issues, and filed
https://issues.apache.org/jira/browse/INFRA-14994

On Wed, Aug 30, 2017 at 4:43 PM, Shazron  wrote:

> I'll request the bulk move tonight since there are no objections
>
>
> On Aug 30, 2017 at 9:55 AM, Steven Gill  wrote:
>
>
> That is a good point.
>
> Those repos are already mirrored on github. I say let them be converted to
> full github repos and then we can deal with archiving/deprecating them.
>
> On Wed, Aug 30, 2017 at 2:07 AM, Filip Maj  wrote:
>
> Should we delete/remove/archive any of those before moving them over?
> We have repos like app harness, medic, and others that are not
> contributed to nor used anymore.
>
> On Tue, Aug 29, 2017 at 10:13 PM, Steven Gill 
> wrote:
>
> We can deal with jira issues -> github issues migration once all repos
>
> are
>
> moved over.
>
> On Tue, Aug 29, 2017 at 11:19 AM, Steven Gill 
> wrote:
>
> do it!
>
>
> On Tue, Aug 29, 2017 at 11:18 AM, Shazron  wrote:
>
> See: https://issues.apache.org/jira/browse/INFRA-14398
>
> INFRA (through Daniel Gruno) has commented on Hipchat that a bulk move
> would be easier for us, versus a selective move.
>
> Ironically the proposed 3 Phase approach was to make it easier for
>
> INFRA
>
> to
> transition us.
>
> Updated proposal:
> Move **all** our repos from git-wip-us.apache.org to Github?
>
> +1 for me.
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>
>
>

Re: [GITHUB MOVE] Bulk move of all repos

[Shazron]

I'll request the bulk move tonight since there are no objections

On Aug 30, 2017 at 9:55 AM, Steven Gill  wrote:


That is a good point.

Those repos are already mirrored on github. I say let them be converted to
full github repos and then we can deal with archiving/deprecating them.

On Wed, Aug 30, 2017 at 2:07 AM, Filip Maj  wrote:

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

On Tue, Aug 29, 2017 at 10:13 PM, Steven Gill 
wrote:

We can deal with jira issues -> github issues migration once all repos

are

moved over.

On Tue, Aug 29, 2017 at 11:19 AM, Steven Gill 
wrote:

do it!


On Tue, Aug 29, 2017 at 11:18 AM, Shazron  wrote:

See: https://issues.apache.org/jira/browse/INFRA-14398

INFRA (through Daniel Gruno) has commented on Hipchat that a bulk move
would be easier for us, versus a selective move.

Ironically the proposed 3 Phase approach was to make it easier for

INFRA

to
transition us.

Updated proposal:
Move **all** our repos from git-wip-us.apache.org to Github?

+1 for me.




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

Re: [GITHUB MOVE] Bulk move of all repos

[Steven Gill]

That is a good point.

Those repos are already mirrored on github. I say let them be converted to
full github repos and then we can deal with archiving/deprecating them.

On Wed, Aug 30, 2017 at 2:07 AM, Filip Maj  wrote:

> Should we delete/remove/archive any of those before moving them over?
> We have repos like app harness, medic, and others that are not
> contributed to nor used anymore.
>
> On Tue, Aug 29, 2017 at 10:13 PM, Steven Gill 
> wrote:
> > We can deal with jira issues -> github issues migration once all repos
> are
> > moved over.
> >
> > On Tue, Aug 29, 2017 at 11:19 AM, Steven Gill 
> > wrote:
> >
> >> do it!
> >>
> >>
> >> On Tue, Aug 29, 2017 at 11:18 AM, Shazron  wrote:
> >>
> >>> See: https://issues.apache.org/jira/browse/INFRA-14398
> >>>
> >>> INFRA (through Daniel Gruno) has commented on Hipchat that a bulk move
> >>> would be easier for us, versus a selective move.
> >>>
> >>> Ironically the proposed 3 Phase approach was to make it easier for
> INFRA
> >>> to
> >>> transition us.
> >>>
> >>> Updated proposal:
> >>> Move **all** our repos from git-wip-us.apache.org to Github?
> >>>
> >>> +1 for me.
> >>>
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [GITHUB MOVE] Bulk move of all repos

[Filip Maj]

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

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

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

Re: [GITHUB MOVE] Bulk move of all repos

[Steven Gill]

We can deal with jira issues -> github issues migration once all repos are
moved over.

On Tue, Aug 29, 2017 at 11:19 AM, Steven Gill 
wrote:

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

Re: [GITHUB MOVE] Bulk move of all repos

[Steven Gill]

do it!


On Tue, Aug 29, 2017 at 11:18 AM, Shazron  wrote:

> See: https://issues.apache.org/jira/browse/INFRA-14398
>
> INFRA (through Daniel Gruno) has commented on Hipchat that a bulk move
> would be easier for us, versus a selective move.
>
> Ironically the proposed 3 Phase approach was to make it easier for INFRA to
> transition us.
>
> Updated proposal:
> Move **all** our repos from git-wip-us.apache.org to Github?
>
> +1 for me.
>

Re: github update

[Steven Gill]

I do agree that having all of cordova's repos under the cordova org would
be better for discoverability. But, it is apache policy that our code live
under apache. That is the main reason you see almost all of our repos
there.

Until recently, apache's github repos were only mirrors of apache hosted
git servers. This meant we weren't allowed to push directly to github. We
also weren't allowed to merge, label or edit from the github interface. Or
have issues there.

Now apache allows us to make our default repo github via gitbox project. So
we have the ability to do all of the things that were previously not
allowed. It made sense to move these 4 repos over to apache since that is
where the rest of our repos are. These four repos never contained anything
we released. They were all meant for tracking and/or discussion purposes.



On Thu, Aug 17, 2017 at 12:22 PM, Jan Piotrowski 
wrote:

> Off-list:
> Why do the repos have to be moved to the apache org? Having a cordova
> org would have been a much better central place to group all and
> highlight the important repos and what is going on.
>
> -J
>
> 2017-08-17 20:34 GMT+02:00 Steven Gill :
> > So we have officially moved 4 repos under apache org from cordova org
> [1].
> >
> > https://github.com/apache/cordova-new-committer-and-pmc
> > https://github.com/apache/cordova-status
> > https://github.com/apache/cordova-apache-board-reports
> > https://github.com/apache/cordova-discuss
> >
> > These four repos will function the same way as they did under cordova
> org.
> > Issues with repo, issue and pr labeling, ability to merge from github
> > interface.
> >
> > We are still working towards moving issues from JIRA into their
> individual
> > repos. You can view the discussion at [2]
> >
> > We have only moved over platform repos to github/gitbox proper so far. We
> > are waiting on Infra for next few repos. [3]
> >
> > Lastly, commits and PR notifications for our new full github repos won't
> be
> > coming to the dev list anymore. They are going to
> comm...@cordova.apache.org.
> > You can subscribe to that list or hit watch on repos you are interested
> in
> > via the github interface (this is what I do)
> >
> > [1] https://issues.apache.org/jira/browse/INFRA-14815
> > [2] https://github.com/apache/cordova-discuss/pull/75
> > [3] https://issues.apache.org/jira/browse/INFRA-14398
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: github update

[Jan Piotrowski]

Off-list:
Why do the repos have to be moved to the apache org? Having a cordova
org would have been a much better central place to group all and
highlight the important repos and what is going on.

-J

2017-08-17 20:34 GMT+02:00 Steven Gill :
> So we have officially moved 4 repos under apache org from cordova org [1].
>
> https://github.com/apache/cordova-new-committer-and-pmc
> https://github.com/apache/cordova-status
> https://github.com/apache/cordova-apache-board-reports
> https://github.com/apache/cordova-discuss
>
> These four repos will function the same way as they did under cordova org.
> Issues with repo, issue and pr labeling, ability to merge from github
> interface.
>
> We are still working towards moving issues from JIRA into their individual
> repos. You can view the discussion at [2]
>
> We have only moved over platform repos to github/gitbox proper so far. We
> are waiting on Infra for next few repos. [3]
>
> Lastly, commits and PR notifications for our new full github repos won't be
> coming to the dev list anymore. They are going to comm...@cordova.apache.org.
> You can subscribe to that list or hit watch on repos you are interested in
> via the github interface (this is what I do)
>
> [1] https://issues.apache.org/jira/browse/INFRA-14815
> [2] https://github.com/apache/cordova-discuss/pull/75
> [3] https://issues.apache.org/jira/browse/INFRA-14398

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

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

[Steven Gill]

GRR

I'm going to request the same for PRs

On Thu, Aug 10, 2017 at 3:01 PM, Filip Maj  wrote:

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

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

[Filip Maj]

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

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

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

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

[Steven Gill]

This email shouldn't be coming to the mailing list right?

On Thu, Aug 10, 2017 at 1:26 PM,  wrote:

> shazron closed pull request #329: CB-13112 -  should not
> create a new file reference on each "cordova prepare"
> URL: https://github.com/apache/cordova-ios/pull/329
>
>
>
>
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> With regards,
> Apache Git Services
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

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

[Steven Gill]

Woo! Thanks shaz!

Time to request phase 2 (tools!)? https://issues.
apache.org/jira/browse/INFRA-14398

Audrey is looking into making a proposal for issue migration. Will share
soon.


On Mon, Aug 7, 2017 at 11:42 AM, Shazron  wrote:

> Fixed coho references:
> https://issues.apache.org/jira/browse/CB-13156
>
> Now that we are using Github for these 4 repos, you need to authenticate
> with Github using https and a personal access token (not your password!).
>
> See:
> https://help.github.com/articles/creating-a-personal-access-
> token-for-the-command-line/
> or use a protected .netrc
>
> If you have existing repos, you will have to update the origin remotes
> yourself, consult the man page for "git-remote"
> The format to use is: https://github.com/apache/REPO_NAME.git
>
>
>
> On Wed, Aug 2, 2017 at 6:55 PM, Steven Gill 
> wrote:
>
> > Yes!
> >
> > On Aug 2, 2017 6:16 PM, "Filip Maj"  wrote:
> >
> > > at some point should we migrate / create a cordova-discuss repo [1] to
> > > the apache org?
> > >
> > > [1] https://github.com/cordova/cordova-discuss
> > >
> > > On Wed, Aug 2, 2017 at 12:42 PM, Shazron  wrote:
> > > > Phase 1 complete:
> > > > https://issues.apache.org/jira/browse/INFRA-14347
> > > >
> > > > We need to:
> > > >
> > > > 1. Update some of our tools, mainly Coho, to point directly to
> Github,
> > > > since the git-wip-us.a.o repo is now gone.
> > > > 2. Update our docs
> > > > 3. Update our website (contribution)
> > > >
> > > > I think we need to do 2. and 3. once Phases 2 and 3 are done as well.
> > > > We can do gradual updates of 1. as repos are migrated (should just
> be a
> > > > json file).
> > > >
> > > > The Git repo now exists on Apache at:
> > > > https://gitbox.apache.org/repos/asf?p=REPO-NAME.git
> > > >
> > > > .. but we will primarily push to Github.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>

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

[Shazron]

Fixed coho references:
https://issues.apache.org/jira/browse/CB-13156

Now that we are using Github for these 4 repos, you need to authenticate
with Github using https and a personal access token (not your password!).

See:
https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/
or use a protected .netrc

If you have existing repos, you will have to update the origin remotes
yourself, consult the man page for "git-remote"
The format to use is: https://github.com/apache/REPO_NAME.git



On Wed, Aug 2, 2017 at 6:55 PM, Steven Gill  wrote:

> Yes!
>
> On Aug 2, 2017 6:16 PM, "Filip Maj"  wrote:
>
> > at some point should we migrate / create a cordova-discuss repo [1] to
> > the apache org?
> >
> > [1] https://github.com/cordova/cordova-discuss
> >
> > On Wed, Aug 2, 2017 at 12:42 PM, Shazron  wrote:
> > > Phase 1 complete:
> > > https://issues.apache.org/jira/browse/INFRA-14347
> > >
> > > We need to:
> > >
> > > 1. Update some of our tools, mainly Coho, to point directly to Github,
> > > since the git-wip-us.a.o repo is now gone.
> > > 2. Update our docs
> > > 3. Update our website (contribution)
> > >
> > > I think we need to do 2. and 3. once Phases 2 and 3 are done as well.
> > > We can do gradual updates of 1. as repos are migrated (should just be a
> > > json file).
> > >
> > > The Git repo now exists on Apache at:
> > > https://gitbox.apache.org/repos/asf?p=REPO-NAME.git
> > >
> > > .. but we will primarily push to Github.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

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

[Steven Gill]

Yes!

On Aug 2, 2017 6:16 PM, "Filip Maj"  wrote:

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

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

[Filip Maj]

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

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

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

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

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

[Filip Maj]

This makes me so happy :)

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

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

Auto-Re: [GitHub] cordova-docs issue #619: CB-11500 Add android@5.2.1 release blog post

[kjczxl]

Auto-Re: [GitHub] cordova-docs pull request #619: CB-11500 Add android@5.2.1 release blog post

[kjczxl]

Auto-Re: [GitHub] cordova-ios issue #225: CB-11352: Call setUserAgent before creating a view

[kjczxl]

Auto-Re: [GitHub] cordova-plugin-wkwebview-engine issue #11: CB-9888: (iOS) check & reload WKW...

[kjczxl]

Auto-Re: [GitHub] cordova-plugin-wkwebview-engine issue #11: CB-9888: (iOS) check & reload WKW...

[kjczxl]

Auto-Re: [GitHub] cordova-plugin-wkwebview-engine issue #11: CB-9888: (iOS) check & reload WKW...

[kjczxl]

Auto-Re: [GitHub] cordova-plugin-camera issue #219: Dont work camera on Android

[kjczxl]

Auto-Re: [GitHub] cordova-docs pull request #618: CB-11522 Do not clone the detail object on a...

[kjczxl]

Auto-Re: [GitHub] cordova-windows pull request #183: CB-11522 Do not clone the detail object o...

[kjczxl]

Auto-Re: [GitHub] cordova-plugin-camera issue #219: Dont work camera on Android

[kjczxl]

Auto-Re: [GitHub] cordova-js pull request #134: CB-11522 Do not clone the detail object on act...

[kjczxl]

Auto-Re: [GitHub] cordova-plugin-camera pull request #222: CB-11498 [Android] Appium tests sho...

[kjczxl]

Auto-Re: [GitHub] cordova-windows pull request #182: CB-11538 Update README with information a...

[kjczxl]

Auto-Re: [GitHub] cordova-windows pull request #181: CB-11537 Do not duplicate log entries whe...

[kjczxl]

Auto-Re: [GitHub] cordova-lib pull request #463: Fixed typos in 'platform' name

[kjczxl]

Auto-Re: [GitHub] cordova-windows issue #144: CB-10446 Windows 10 Cordova Application restart ...

[kjczxl]

Auto-Re: [GitHub] cordova-lib issue #463: Fixed typos in 'platform' name

[kjczxl]

Auto-Re: [GitHub] cordova-lib pull request #463: Fixed typos in 'platform' name

[kjczxl]

RE: Github issue and PR templates

[Nikhil Khandelwal]

I have submitted a PR to add a pull request to cordova-plugin-camera: 
https://github.com/apache/cordova-plugin-camera/pull/213

Please review and provide feedback. I intend to add this to all other repos.

-Nikhil

-Original Message-
From: Dmitry Blotsky [mailto:dblot...@microsoft.com] 
Sent: Thursday, February 18, 2016 6:39 PM
To: dev@cordova.apache.org
Subject: RE: Github issue and PR templates

I like the idea. I suggest starting small and expanding as necessary. Right now 
the two most important pieces of information that I think our PRs could use are:

Did you sign the ICLA? [ ] Yes / [ ] No
Related JIRA: CB-[ ]

Kindly,
Dmitry

-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com]
Sent: Thursday, February 18, 2016 5:55 PM
To: dev@cordova.apache.org
Subject: Re: Github issue and PR templates

I agree, Running tests as easy as npm install && npm run config && npm test
 :-)


On Thu, Feb 18, 2016 at 4:40 PM Nikhil Khandelwal <nikhi...@microsoft.com>
wrote:

> I think for plugins, platform name should be required as part of title 
> of the PR and commit message in addition to JIRA number.
>
> Checklist:
> [ ] Tests that were added or run for a new feature/regressions [ ] 
> Does the new feature broadly apply to multiple platforms?
>
> We probably need to make it easier for contributors to run tests for 
> plugins.
>
> -Nikhil
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, February 17, 2016 1:42 PM
> To: dev@cordova.apache.org
> Subject: Github issue and PR templates
>
> Cool new feature from github!
> https://github.com/blog/2111-issue-and-pull-request-templates
>
> Since we don't do issues on github, that feature isn't useful to us. 
> But providing PR templates sounds like a good idea. Just need to add a 
> PULL_REQUEST_TEMPLATE.md to the root of our repos.
>
> What type of information would we ask for from PRs?
>
> * Issue number
>
> If it is a plugin
> * which platforms
>
> Thoughts?
>

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

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

Re: [GitHub] cordova-cli pull request: Telemetry

[Jesse]

+1


@purplecabbage
risingj.com

On Mon, May 9, 2016 at 5:08 PM, stevengill  wrote:

> Github user stevengill commented on the pull request:
>
> https://github.com/apache/cordova-cli/pull/247#issuecomment-218025705
>
> LGTM!!
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [GitHub] cordova-plugin-device-motion pull request: CB-10400 Added Appium t...

[Jesse]

Thanks @alsorokin!
Can you include instructions on how to run the tests also? Please, please.


@purplecabbage
risingj.com

On Mon, Apr 25, 2016 at 12:32 AM, alsorokin  wrote:

> Github user alsorokin commented on the pull request:
>
>
> https://github.com/apache/cordova-plugin-device-motion/pull/39#issuecomment-214183578
>
> @infil00p i've just added a small guide on how to run cordova Appium
> tests here:
> https://github.com/apache/cordova-medic/blob/master/APPIUM.md
>
> This PR is pretty old and these tests can only run on mobilespec. I
> will update it to make the tests more generic and stable.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [GitHub] cordova-plugin-file pull request: adding sample section to readme

[Robert Posener]

1. Browser platform... the one under discussion.
2. I understood everything you say in your response paragraphs 2 and 3.
3. My points still remain... your statement "many of these APIs..." is
confusing.
4. Your words in paragraphs 2 and 3 of your response should be included as
clarification.
5. Replace "I believe it" with "Chrome Version 49.0.2623.112 m still works,
but there is no guarantee that this will continue."

Regards

Rob

Regards
*Rob Posener*
0419 012 627

On 8 April 2016 at 08:44, jasongin  wrote:

> Github user jasongin commented on the pull request:
>
>
> https://github.com/apache/cordova-plugin-file/pull/176#issuecomment-207123605
>
> Rob, what platform are you looking at?
>
> The W3C FileSystems spec for web browsers is deprecated; what that
> effectively means is no other browsers will implement the spec. Chrome was
> the only browser to ever implement that spec, and I believe it still works
> in current builds of Chrome
>
> However, the Cordova file plugin implements that spec as a polyfill
> for Cordova platforms other than the "Browser" platform (because the
> Browser platform isn't able to call native plugin APIs). So it makes the
> deprecation of the spec mostly irrelevant for Cordova app developers.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: GitHub pull request housekeeping

[Jesse]

Yeah, I also have done the allow-empty way:
git commit --allow-empty -m "Closing stale pull requests: close #99, close
#46, close #82" ...




@purplecabbage
risingj.com

On Wed, Mar 23, 2016 at 12:01 PM, Carlos Santana 
wrote:

> I have done cleaning by using coho instructions on other repos in the past
>
> You can close multiple PRs with one commit
>
> - Carlos
> @csantanapr
>
> > On Mar 23, 2016, at 4:10 PM, julio cesar sanchez 
> wrote:
> >
> > On cordova coho there is a section "Stale Pull Requests"
> >
> > To close a pull request that is no longer relevant / active:
> >
> >   - Create an empty commit in the repo of the pull request via:
> >  - `git commit --allow-empty -m "Closing stale pull request: close
> #99"
> >
> > So I think it can be done without editing the README.md (never tried)
> >
> >
> > I sometimes ask the PR owner to close it if it's not going to be merged,
> > but if he doesn't close it in a few days we can do this.
> >
> >
> >
> >
> >
> > 2016-03-23 21:05 GMT+01:00 Joe Bowser :
> >
> >> Hey
> >>
> >> So, I don't know about the other repositories, but cordova-android on
> >> GitHub has a lot of pull requests that are obviously never going to be
> >> accepted because they're out of date or are not on the master branch.
> >> Since we have no plans to merge things onto 3.7.x or the 4.1.x
> branches, it
> >> would be good if we could somehow close them.
> >>
> >> AFAIK, the only way we can close them is by editing README.md and
> putting
> >> in the git message. "This closes #", but it would be
> kind
> >> of annoying to have to do that.  That said, may be we should do that for
> >> housekeeping.
> >>
> >> What do people think?
> >>
> >> Joe
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: GitHub pull request housekeeping

[Carlos Santana]

I have done cleaning by using coho instructions on other repos in the past 

You can close multiple PRs with one commit

- Carlos
@csantanapr

> On Mar 23, 2016, at 4:10 PM, julio cesar sanchez  
> wrote:
> 
> On cordova coho there is a section "Stale Pull Requests"
> 
> To close a pull request that is no longer relevant / active:
> 
>   - Create an empty commit in the repo of the pull request via:
>  - `git commit --allow-empty -m "Closing stale pull request: close #99"
> 
> So I think it can be done without editing the README.md (never tried)
> 
> 
> I sometimes ask the PR owner to close it if it's not going to be merged,
> but if he doesn't close it in a few days we can do this.
> 
> 
> 
> 
> 
> 2016-03-23 21:05 GMT+01:00 Joe Bowser :
> 
>> Hey
>> 
>> So, I don't know about the other repositories, but cordova-android on
>> GitHub has a lot of pull requests that are obviously never going to be
>> accepted because they're out of date or are not on the master branch.
>> Since we have no plans to merge things onto 3.7.x or the 4.1.x branches, it
>> would be good if we could somehow close them.
>> 
>> AFAIK, the only way we can close them is by editing README.md and putting
>> in the git message. "This closes #", but it would be kind
>> of annoying to have to do that.  That said, may be we should do that for
>> housekeeping.
>> 
>> What do people think?
>> 
>> Joe
>> 

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

Re: GitHub pull request housekeeping

[julio cesar sanchez]

On cordova coho there is a section "Stale Pull Requests"

To close a pull request that is no longer relevant / active:

   - Create an empty commit in the repo of the pull request via:
  - `git commit --allow-empty -m "Closing stale pull request: close #99"

So I think it can be done without editing the README.md (never tried)


I sometimes ask the PR owner to close it if it's not going to be merged,
but if he doesn't close it in a few days we can do this.





2016-03-23 21:05 GMT+01:00 Joe Bowser :

> Hey
>
> So, I don't know about the other repositories, but cordova-android on
> GitHub has a lot of pull requests that are obviously never going to be
> accepted because they're out of date or are not on the master branch.
> Since we have no plans to merge things onto 3.7.x or the 4.1.x branches, it
> would be good if we could somehow close them.
>
> AFAIK, the only way we can close them is by editing README.md and putting
> in the git message. "This closes #", but it would be kind
> of annoying to have to do that.  That said, may be we should do that for
> housekeeping.
>
> What do people think?
>
> Joe
>

Re: [GitHub] cordova-lib pull request: CB-9858 Cordova Fetch Work

[manish varma]

cool

On Wed, Mar 9, 2016 at 12:53 PM, stevengill  wrote:

> Github user stevengill commented on a diff in the pull request:
>
> https://github.com/apache/cordova-lib/pull/407#discussion_r55480177
>
> --- Diff: cordova-fetch/index.js ---
> @@ -0,0 +1,176 @@
> +/**
> + Licensed to the Apache Software Foundation (ASF) under one
> + or more contributor license agreements.  See the NOTICE file
> + distributed with this work for additional information
> + regarding copyright ownership.  The ASF licenses this file
> + to you under the Apache License, Version 2.0 (the
> + 'License'); you may not use this file except in compliance
> + with the License.  You may obtain a copy of the License at
> +
> + http://www.apache.org/licenses/LICENSE-2.0
> +
> + Unless required by applicable law or agreed to in writing,
> + software distributed under the License is distributed on an
> + 'AS IS' BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + KIND, either express or implied.  See the License for the
> + specific language governing permissions and limitations
> + under the License.
> + */
> +
> +var Q = require('q');
> +var shell = require('shelljs');
> +var superspawn = require('cordova-common').superspawn;
> +var events = require('cordova-common').events;
> +var depls = require('dependency-ls');
> +var path = require('path');
> +var fs = require('fs');
> +var CordovaError = require('cordova-common').CordovaError;
> +var isUrl = require('is-url');
> +
> +/*
> + * A module that npm installs a module from npm or a git url
> + *
> + * @param {String} target   the packageID or git url
> + * @param {String} dest destination of where to install the module
> + * @param {Object} opts [opts={save:true}] options to pass to
> fetch module
> + *
> + * @return {String||Promise}Returns string of the absolute path
> to the installed module.
> + *
> + */
> +module.exports = function(target, dest, opts) {
> +var fetchArgs = ['install'];
> +opts = opts || {};
> +var tree1;
> +
> +if(!shell.which('npm')) {
> +return Q.reject(new CordovaError('"npm" command line tool is
> not installed: make sure it is accessible on your PATH.'));
> +}
> +
> +if(dest && target) {
> +//add target to fetchArgs Array
> +fetchArgs.push(target);
> +
> +//append node_modules to dest if it doesn't come included
> +if (path.basename(dest) !== 'node_modules') {
> +dest = path.resolve(path.join(dest, 'node_modules'));
> +}
> +
> +//create dest if it doesn't exist
> +if(!fs.existsSync(dest)) {
> +shell.mkdir('-p', dest);
> +}
> +
> +} else return Q.reject(new CordovaError('Need to supply a target
> and destination'));
> +
> +//set the directory where npm install will be run
> +opts.cwd = dest;
> --- End diff --
>
> Yup! Pass everything to superspawn that fetch was passed. Add the cwd
> to opts though.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>


-- 
Regards
Manish Varma D
+91-9538612399
LinkedIn: //in.linkedin.com/pub/manish-varma-d/86/66a/ab
Think Green: Please consider the environment before printing this e-mail.Privy
Notice: This is a confidential email. If you are not the expected
recipient, we alert you that this email has reached you by error and
disclosing of the contents to any other source is strictly prohibited. If
you have received this email by error, you are requested to acknowledge and
delete the message immediately.

RE: Github issue and PR templates

[Dmitry Blotsky]

I like the idea. I suggest starting small and expanding as necessary. Right now 
the two most important pieces of information that I think our PRs could use are:

Did you sign the ICLA? [ ] Yes / [ ] No
Related JIRA: CB-[ ]

Kindly,
Dmitry

-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com] 
Sent: Thursday, February 18, 2016 5:55 PM
To: dev@cordova.apache.org
Subject: Re: Github issue and PR templates

I agree, Running tests as easy as npm install && npm run config && npm test
 :-)


On Thu, Feb 18, 2016 at 4:40 PM Nikhil Khandelwal <nikhi...@microsoft.com>
wrote:

> I think for plugins, platform name should be required as part of title 
> of the PR and commit message in addition to JIRA number.
>
> Checklist:
> [ ] Tests that were added or run for a new feature/regressions [ ] 
> Does the new feature broadly apply to multiple platforms?
>
> We probably need to make it easier for contributors to run tests for 
> plugins.
>
> -Nikhil
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, February 17, 2016 1:42 PM
> To: dev@cordova.apache.org
> Subject: Github issue and PR templates
>
> Cool new feature from github!
> https://github.com/blog/2111-issue-and-pull-request-templates
>
> Since we don't do issues on github, that feature isn't useful to us. 
> But providing PR templates sounds like a good idea. Just need to add a 
> PULL_REQUEST_TEMPLATE.md to the root of our repos.
>
> What type of information would we ask for from PRs?
>
> * Issue number
>
> If it is a plugin
> * which platforms
>
> Thoughts?
>

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

Re: Github issue and PR templates

[Carlos Santana]

I agree, Running tests as easy as npm install && npm run config && npm test
 :-)


On Thu, Feb 18, 2016 at 4:40 PM Nikhil Khandelwal 
wrote:

> I think for plugins, platform name should be required as part of title of
> the PR and commit message in addition to JIRA number.
>
> Checklist:
> [ ] Tests that were added or run for a new feature/regressions
> [ ] Does the new feature broadly apply to multiple platforms?
>
> We probably need to make it easier for contributors to run tests for
> plugins.
>
> -Nikhil
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, February 17, 2016 1:42 PM
> To: dev@cordova.apache.org
> Subject: Github issue and PR templates
>
> Cool new feature from github!
> https://github.com/blog/2111-issue-and-pull-request-templates
>
> Since we don't do issues on github, that feature isn't useful to us. But
> providing PR templates sounds like a good idea. Just need to add a
> PULL_REQUEST_TEMPLATE.md to the root of our repos.
>
> What type of information would we ask for from PRs?
>
> * Issue number
>
> If it is a plugin
> * which platforms
>
> Thoughts?
>

RE: Github issue and PR templates

[Nikhil Khandelwal]

I think for plugins, platform name should be required as part of title of the 
PR and commit message in addition to JIRA number. 

Checklist:
[ ] Tests that were added or run for a new feature/regressions
[ ] Does the new feature broadly apply to multiple platforms?

We probably need to make it easier for contributors to run tests for plugins.

-Nikhil

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com] 
Sent: Wednesday, February 17, 2016 1:42 PM
To: dev@cordova.apache.org
Subject: Github issue and PR templates

Cool new feature from github!
https://github.com/blog/2111-issue-and-pull-request-templates

Since we don't do issues on github, that feature isn't useful to us. But 
providing PR templates sounds like a good idea. Just need to add a 
PULL_REQUEST_TEMPLATE.md to the root of our repos.

What type of information would we ask for from PRs?

* Issue number

If it is a plugin
* which platforms

Thoughts?

Re: [GitHub] cordova-windows pull request: CB-10440 Add CSS color names support...

[Robert Posener]

Or is it platform dependent (ie, is the list of colours dependent upon the
WebView implementation)?  So, when the WebView is revised, it will take
care of allowing new colours, instead of developers pointing the finger at
Cordova for not keeping up-to-date with revised colour names?

Rob

Regards
*Rob Posener*
0419 012 627

On 27 January 2016 at 13:35, dblotsky  wrote:

> Github user dblotsky commented on a diff in the pull request:
>
>
> https://github.com/apache/cordova-windows/pull/142#discussion_r50934617
>
> --- Diff: template/cordova/lib/AppxManifest.js ---
> @@ -374,6 +374,11 @@ AppxManifest.prototype.getCapabilities = function
> () {
>  };
>
>  function refineColor(color) {
> +if (color.indexOf('0x') === -1 && color.indexOf('#') === -1) {
> --- End diff --
>
> Is there a list of valid CSS colours? For example, `meow` and `12345`
> and are not colours, but they will get accepted here.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [GitHub] cordova-plugin-inappbrowser pull request: CB-10009 Improve InAppBr...

[Jesse]

Great!
I don't know how those last buttons made it in, but they were UGLY!


@purplecabbage
risingj.com

On Mon, Jan 11, 2016 at 3:26 AM, sgrebnov  wrote:

> Github user sgrebnov commented on the pull request:
>
>
> https://github.com/apache/cordova-plugin-inappbrowser/pull/129#issuecomment-170513142
>
> Re-based on top of master and merged
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [GitHub] cordova-plugin-contacts pull request: CB-8115 Save contact birthda...

[Jesse]

The issue is that the date object is not stored in a method that is
compatible with other applications on the android device.
This is strictly a native issue, and as Vlad said, not testable via our own
automated tests.
We get back exactly what we store, so our current tests all pass.  The
native code just needs to store/retrieve it in a format compatible with
other apps.  This should have zero impact on other platforms and zero
impact on the js code.


@purplecabbage
risingj.com

On Wed, Dec 2, 2015 at 2:14 PM, riknoll  wrote:

> Github user riknoll commented on the pull request:
>
>
> https://github.com/apache/cordova-plugin-contacts/pull/95#issuecomment-161450864
>
> @vladimir-kotikov is the issue that Android saves the date in a
> different format from other platforms? If that is the case, I guess the
> greater issue is lack of consistency in the API as to how contacts are
> presented in the JS. That sounds like a separate issue to me, but one that
> should be addressed.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [GitHub] cordova-ios pull request: CB-9883 - Remove unused iOS bridges

[Jesse]

And that we need to watch what others commit. More review would have stopped 
this in the first place. 

> On Nov 5, 2015, at 6:33 PM, csantanapr  wrote:
> 
> Github user csantanapr commented on the pull request:
> 
>https://github.com/apache/cordova-ios/pull/178#issuecomment-154265526
> 
>@shazron is this a lesson learned that certain experimental things should 
> be kept in experimental branches and not in master :+1: 
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
> 

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

Re: [GitHub] cordova-plugin-file-transfer pull request: getCookies bugfix

[Jesse]

Post a picture that fails so we can verify. 

> On Nov 3, 2015, at 3:30 AM, jeroenv  wrote:
> 
> Github user jeroenv commented on the pull request:
> 
>
> https://github.com/apache/cordova-plugin-file-transfer/pull/107#issuecomment-153325389
> 
>@daserge I forgot to mention that this bug only seems to happen with 
> certain pictures you try to upload from Gallery/Dropbox/Google Drive. If you 
> pick a picture from Photos or take a new picture and upload it everything 
> works fine.
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
> 

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

Re: [GitHub] cordova-plugin-file pull request: CB-7253: requestFileSystem fails...

[Jesse]

I thought the whole KiB thing was a geek joke. I had no idea it even
existed until I saw all of the text related to image resources allowed for
submitting apps to the showcase. ( Which I also thought was an entirely
tongue in cheek request ... )


@purplecabbage
risingj.com

On Sat, Oct 31, 2015 at 1:15 PM, dblotsky  wrote:

> Github user dblotsky commented on a diff in the pull request:
>
>
> https://github.com/apache/cordova-plugin-file/pull/145#discussion_r43575761
>
> --- Diff: src/android/DirectoryManager.java ---
> @@ -56,45 +56,46 @@ public static boolean testFileExists(String name) {
>  }
>
>  /**
> - * Get the free disk space
> - *
> + * Get the free space in external storage
> + *
>   * @return Size in KB or -1 if not available
> --- End diff --
>
> Hah, I actually didn't know that the tradition has been for KB to mean
> 1024. I had someone drill KiB into me recently, so I was under the
> impression that KiB were the way to go. Thanks for disillusioning me!
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [GitHub] cordova-android pull request: API for saving/restoring plugin and ...

[Jesse]

This sounds really good!
The only reservation I have is making a new non-standard way of saving
state in js.

Instead of providing navigator.app.saveState() I think we should be content
to simply raise the event, and allow the app developer to choose how they
wish to store it.  The obvious choice would be simply dumping some data in
localStorage.


@purplecabbage
risingj.com

On Wed, Oct 28, 2015 at 1:52 PM, riknoll  wrote:

> Github user riknoll commented on the pull request:
>
>
> https://github.com/apache/cordova-android/pull/236#issuecomment-151986714
>
> Here's an example index.js and index.html:
> https://gist.github.com/riknoll/94a40dc147040191fd3e
>
> For anyone hoping to test it out, make sure you check "Don't keep
> activities" in your phone's developer options.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

RE: [GitHub] cordova-android pull request: API for saving/restoring plugin and ...

[Richard Knoll]

That's a pretty good point. When I was working on it, I figured that since this 
was a platform specific issue, mimicking the platform's API (Android's 
onSaveInstanceState) was the way to go. Expanding CoreAndroid's secret APIs is 
probably worth avoiding though.

Thanks,
Richard

-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com] 
Sent: Wednesday, October 28, 2015 2:49 PM
To: dev@cordova.apache.org
Subject: Re: [GitHub] cordova-android pull request: API for saving/restoring 
plugin and ...

This sounds really good!
The only reservation I have is making a new non-standard way of saving state in 
js.

Instead of providing navigator.app.saveState() I think we should be content to 
simply raise the event, and allow the app developer to choose how they wish to 
store it.  The obvious choice would be simply dumping some data in localStorage.


@purplecabbage
https://na01.safelinks.protection.outlook.com/?url=risingj.com=01%7c01%7cRIKNOLL%40exchange.microsoft.com%7c43887f38590b4cf68f2908d2dfe1b049%7c72f988bf86f141af91ab2d7cd011db47%7c1=S4Sqckds4SE%2f%2fngCXBWQxZkvofnRUIUgn0x9J0krBO0%3d

On Wed, Oct 28, 2015 at 1:52 PM, riknoll <g...@git.apache.org> wrote:

> Github user riknoll commented on the pull request:
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2fapache%2fcordova-android%2fpull%2f236%23issuecomment-151986714
> =01%7c01%7cRIKNOLL%40exchange.microsoft.com%7c43887f38590b4cf68f2
> 908d2dfe1b049%7c72f988bf86f141af91ab2d7cd011db47%7c1=pSCIkGF0LeL
> 9R224b1tsyXH83iYwszeDAT1zxlpfQsQ%3d
>
> Here's an example index.js and index.html:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgist.
> github.com%2friknoll%2f94a40dc147040191fd3e=01%7c01%7cRIKNOLL%40e
> xchange.microsoft.com%7c43887f38590b4cf68f2908d2dfe1b049%7c72f988bf86f
> 141af91ab2d7cd011db47%7c1=5CXyfzbtGMcv%2fnicW7PZffrxnykSiOo4Jk5X
> wLGKcIA%3d
>
> For anyone hoping to test it out, make sure you check "Don't keep 
> activities" in your phone's developer options.
>
>
> ---
> If your project is set up for it, you can reply to this email and have 
> your reply appear on GitHub as well. If your project does not have 
> this feature enabled and wishes so, or if the feature is enabled but 
> not working, please contact infrastructure at 
> infrastruct...@apache.org or file a JIRA ticket with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

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

Re: [GitHub] cordova-ios pull request: CB-9685 A fix for the magnifying glass p...

[julio cesar sanchez]

Ok, forget about the -webkit-user-select: none; part, you might put that on
the body but use -webkit-user-select: text; on input type text and textarea.

2015-10-22 13:03 GMT+02:00 julio cesar sanchez :

> +1 for preference
>
> but I think the problem the plugin solves only appears when you add the
> css to avoid text selection (-webkit-user-select: none;), so if the user
> wants text selection he won't add that css and he doesn't need the plugin.
>
> BTW, I'm not able to reproduce the magnifier glass issue on iOS 9.1, maybe
> apple fixed it?
>
>
> 2015-10-22 12:18 GMT+02:00 EddyVerbruggen :
>
>> Github user EddyVerbruggen commented on the pull request:
>>
>> https://github.com/apache/cordova-ios/pull/164#issuecomment-150170110
>>
>> I think I'll be adding a configuration for this to config.xml as not
>> all folks may like this feature (new PR).
>>
>> The plugin that inspired this PR has been around for a few weeks now:
>> https://github.com/EddyVerbruggen/cordova-plugin-ios-longpress-fix and
>> while most like it, it may break text selection. If your app needs that
>> this feature will cause trouble.
>>
>> I propose enabling this private plugin only when a certain config.xml
>> property has been enabled.
>>
>> And I'd also like to add a feature to suppress the magnifying glass
>> for devices with 3D Touch support. In the plugin mentioned above I've
>> already done so, by specifying a preference: `> name="Suppress3DTouch" value="true" />`.
>>
>> Any thoughts others want to share perhaps?
>>
>>
>> ---
>> If your project is set up for it, you can reply to this email and have
>> your
>> reply appear on GitHub as well. If your project does not have this feature
>> enabled and wishes so, or if the feature is enabled but not working,
>> please
>> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
>> with INFRA.
>> ---
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>
>

Re: [GitHub] cordova-ios pull request: CB-9685 A fix for the magnifying glass p...

[julio cesar sanchez]

+1 for preference

but I think the problem the plugin solves only appears when you add the css
to avoid text selection (-webkit-user-select: none;), so if the user wants
text selection he won't add that css and he doesn't need the plugin.

BTW, I'm not able to reproduce the magnifier glass issue on iOS 9.1, maybe
apple fixed it?

2015-10-22 12:18 GMT+02:00 EddyVerbruggen :

> Github user EddyVerbruggen commented on the pull request:
>
> https://github.com/apache/cordova-ios/pull/164#issuecomment-150170110
>
> I think I'll be adding a configuration for this to config.xml as not
> all folks may like this feature (new PR).
>
> The plugin that inspired this PR has been around for a few weeks now:
> https://github.com/EddyVerbruggen/cordova-plugin-ios-longpress-fix and
> while most like it, it may break text selection. If your app needs that
> this feature will cause trouble.
>
> I propose enabling this private plugin only when a certain config.xml
> property has been enabled.
>
> And I'd also like to add a feature to suppress the magnifying glass
> for devices with 3D Touch support. In the plugin mentioned above I've
> already done so, by specifying a preference: ` name="Suppress3DTouch" value="true" />`.
>
> Any thoughts others want to share perhaps?
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [GitHub] cordova-lib pull request: CB-8993 Plugin restore ignores search pa...

[Jesse]

Confirmed here: https://people.apache.org/committer-index.html
Middle name and all ...


My team is hiring!
@purplecabbage
risingj.com

On Fri, Sep 4, 2015 at 4:36 PM, marcuspridham  wrote:

> Github user marcuspridham commented on the pull request:
>
> https://github.com/apache/cordova-lib/pull/292#issuecomment-137878645
>
> Yep.  I signed the ICLA awhile ago.  I have done some pull requests to
> Cordova before.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

RE: [GitHub] cordova-lib pull request: Adds implementation for PlatformApiPoly ...

[Vladimir Kotikov (Akvelon)]

Sure, Jesse.

Best regards, Vladimir.

-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com] 
Sent: Wednesday, August 26, 2015 3:58 AM
To: dev@cordova.apache.org
Subject: Re: [GitHub] cordova-lib pull request: Adds implementation for 
PlatformApiPoly ...

This looks great, but I would like to spend a little more time before we push 
it to master.
Can we hold off until the end of the week?


My team is hiring!
@purplecabbage
https://na01.safelinks.protection.outlook.com/?url=risingj.comdata=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c828d73bbfb0040b208ca08d2adb17adc%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=82e0uXsUaTTV%2bulynRSm3qAvSwui0W%2bqq2yihY9qMj0%3d

On Tue, Aug 25, 2015 at 5:46 PM, stevengill g...@git.apache.org wrote:

 Github user stevengill commented on the pull request:

 
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
 b.com%2fapache%2fcordova-lib%2fpull%2f282%23issuecomment-134780081dat
 a=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c828d73bbfb0040b208ca08
 d2adb17adc%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=SE15OBPRL%2fqm
 ViOBsL0P0yvzKFA5bqAVOkHtPkfDYKI%3d

 Looks great Vlad!  I'm fine with you merging this in and us 
 spending some time testing it on master to make sure it works with all 
 of our platforms.


 ---
 If your project is set up for it, you can reply to this email and have 
 your reply appear on GitHub as well. If your project does not have 
 this feature enabled and wishes so, or if the feature is enabled but 
 not working, please contact infrastructure at 
 infrastruct...@apache.org or file a JIRA ticket with INFRA.
 ---

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

Re: [GitHub] cordova-lib pull request: Adds implementation for PlatformApiPoly ...

[Jesse]

This looks great, but I would like to spend a little more time before we
push it to master.
Can we hold off until the end of the week?


My team is hiring!
@purplecabbage
risingj.com

On Tue, Aug 25, 2015 at 5:46 PM, stevengill g...@git.apache.org wrote:

 Github user stevengill commented on the pull request:

 https://github.com/apache/cordova-lib/pull/282#issuecomment-134780081

 Looks great Vlad!  I'm fine with you merging this in and us spending
 some time testing it on master to make sure it works with all of our
 platforms.


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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

Re: [GitHub] cordova-plugin-file pull request: Added cdvfile protocol purpose d...

[Raymond Camden]

Wow, *very* nice addition to the docs here - thank you @daserge.

On Mon, Jun 29, 2015 at 7:31 AM, daserge g...@git.apache.org wrote:
 GitHub user daserge opened a pull request:

 https://github.com/apache/cordova-plugin-file/pull/120

 Added cdvfile protocol purpose description and examples



 You can merge this pull request into a Git repository by running:

 $ git pull https://github.com/MSOpenTech/cordova-plugin-file cdvfile-docs

 Alternatively you can review and apply these changes as the patch at:

 https://github.com/apache/cordova-plugin-file/pull/120.patch

 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:

 This closes #120

 
 commit 9069da075bf7bbf4a652e3355c26b27edc5d613c
 Author: daserge dase...@yandex.ru
 Date:   2015-06-29T12:27:09Z

 Added cdvfile protocol purpose description and examples

 


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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




-- 
===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

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

Re: [GitHub] cordova-wp8 pull request: Remove `ecosystem:cordova` keyword from ...

[Jesse]

merge it!

@purplecabbage
risingj.com

On Mon, Jun 15, 2015 at 5:46 PM, nikhilkh g...@git.apache.org wrote:

 GitHub user nikhilkh opened a pull request:

 https://github.com/apache/cordova-wp8/pull/83

 Remove `ecosystem:cordova` keyword from package.json



 You can merge this pull request into a Git repository by running:

 $ git pull https://github.com/MSOpenTech/cordova-wp8
 package_ecosystem_cordova

 Alternatively you can review and apply these changes as the patch at:

 https://github.com/apache/cordova-wp8/pull/83.patch

 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:

 This closes #83

 
 commit 3799b274df6d0a9a56b4889fe2bc7f32d46e7ca3
 Author: Nikhil Khandelwal nikhi...@microsoft.com
 Date:   2015-06-16T00:41:18Z

 Remove `ecosystem:cordova` keyword from package.json

 


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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

Re: [GitHub] cordova-cli pull request: CB-5578 Adds `clean` command to cordova-...

[Raymond Camden]

I looked at the bug referenced by this PR
(https://issues.apache.org/jira/browse/CB-5578), but the bug doesn't
say what this new command actually does. I can guess, but can someone
explain exactly what this new feature does? Forgive me if I missed the
mail on this.

On Tue, Jun 9, 2015 at 9:48 AM, vladimir-kotikov g...@git.apache.org wrote:
 GitHub user vladimir-kotikov opened a pull request:

 https://github.com/apache/cordova-cli/pull/216

 CB-5578 Adds `clean` command to cordova-cli



 You can merge this pull request into a Git repository by running:

 $ git pull https://github.com/MSOpenTech/cordova-cli CB-5578

 Alternatively you can review and apply these changes as the patch at:

 https://github.com/apache/cordova-cli/pull/216.patch

 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:

 This closes #216

 
 commit fbc241b8083a0005cb154668d5ad3b28782ae60c
 Author: Vladimir Kotikov v-vlk...@microsoft.com
 Date:   2015-06-09T13:41:08Z

 CB-5578 Adds `clean` command to cordova-cli

 


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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




-- 
===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

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

RE: [GitHub] cordova-cli pull request: CB-5578 Adds `clean` command to cordova-...

[Vladimir Kotikov (Akvelon)]

As Shazron mentioned in JIRA issue - ...this feature should delegate to the 
clean commands for each platform.
That is, 'clean' command just runs the 'clean' script for each platform.  What 
exactly does that script is depends on platform, but in most cases it runs 
build system with clean task, or just removes build output directories. E.g.;
* Android: 'gradle clean' or  'ant clean',
* iOS: 'xcodebuild -project projectName -configuration Debug -alltargets 
clean',
* Windows: 'rm -rf project\platforms\windows\AppPackages  rm -rf 
project\platforms\windows\build',
etc.

---
Best regards, Vladimir

-Original Message-
From: Raymond Camden [mailto:raymondcam...@gmail.com] 
Sent: Wednesday, 10 June, 2015 15:56
To: dev@cordova.apache.org
Subject: Re: [GitHub] cordova-cli pull request: CB-5578 Adds `clean` command to 
cordova-...

I looked at the bug referenced by this PR 
(https://issues.apache.org/jira/browse/CB-5578), but the bug doesn't say what 
this new command actually does. I can guess, but can someone explain exactly 
what this new feature does? Forgive me if I missed the mail on this.

On Tue, Jun 9, 2015 at 9:48 AM, vladimir-kotikov g...@git.apache.org wrote:
 GitHub user vladimir-kotikov opened a pull request:

 https://github.com/apache/cordova-cli/pull/216

 CB-5578 Adds `clean` command to cordova-cli



 You can merge this pull request into a Git repository by running:

 $ git pull https://github.com/MSOpenTech/cordova-cli CB-5578

 Alternatively you can review and apply these changes as the patch at:

 https://github.com/apache/cordova-cli/pull/216.patch

 To close this pull request, make a commit to your master/trunk branch 
 with (at least) the following in the commit message:

 This closes #216

 
 commit fbc241b8083a0005cb154668d5ad3b28782ae60c
 Author: Vladimir Kotikov v-vlk...@microsoft.com
 Date:   2015-06-09T13:41:08Z

 CB-5578 Adds `clean` command to cordova-cli

 


 ---
 If your project is set up for it, you can reply to this email and have 
 your reply appear on GitHub as well. If your project does not have 
 this feature enabled and wishes so, or if the feature is enabled but 
 not working, please contact infrastructure at 
 infrastruct...@apache.org or file a JIRA ticket with INFRA.
 ---

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




--
===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

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

Re: [GitHub] cordova-cli pull request: CB-5578 Adds `clean` command to cordova-...

[Raymond Camden]

Ah - thank you!

On Wed, Jun 10, 2015 at 9:02 AM, Vladimir Kotikov (Akvelon)
v-vlk...@microsoft.com wrote:
 As Shazron mentioned in JIRA issue - ...this feature should delegate to the 
 clean commands for each platform.
 That is, 'clean' command just runs the 'clean' script for each platform.  
 What exactly does that script is depends on platform, but in most cases it 
 runs build system with clean task, or just removes build output directories. 
 E.g.;
 * Android: 'gradle clean' or  'ant clean',
 * iOS: 'xcodebuild -project projectName -configuration Debug -alltargets 
 clean',
 * Windows: 'rm -rf project\platforms\windows\AppPackages  rm -rf 
 project\platforms\windows\build',
 etc.

 ---
 Best regards, Vladimir

 -Original Message-
 From: Raymond Camden [mailto:raymondcam...@gmail.com]
 Sent: Wednesday, 10 June, 2015 15:56
 To: dev@cordova.apache.org
 Subject: Re: [GitHub] cordova-cli pull request: CB-5578 Adds `clean` command 
 to cordova-...

 I looked at the bug referenced by this PR 
 (https://issues.apache.org/jira/browse/CB-5578), but the bug doesn't say what 
 this new command actually does. I can guess, but can someone explain exactly 
 what this new feature does? Forgive me if I missed the mail on this.

 On Tue, Jun 9, 2015 at 9:48 AM, vladimir-kotikov g...@git.apache.org wrote:
 GitHub user vladimir-kotikov opened a pull request:

 https://github.com/apache/cordova-cli/pull/216

 CB-5578 Adds `clean` command to cordova-cli



 You can merge this pull request into a Git repository by running:

 $ git pull https://github.com/MSOpenTech/cordova-cli CB-5578

 Alternatively you can review and apply these changes as the patch at:

 https://github.com/apache/cordova-cli/pull/216.patch

 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:

 This closes #216

 
 commit fbc241b8083a0005cb154668d5ad3b28782ae60c
 Author: Vladimir Kotikov v-vlk...@microsoft.com
 Date:   2015-06-09T13:41:08Z

 CB-5578 Adds `clean` command to cordova-cli

 


 ---
 If your project is set up for it, you can reply to this email and have
 your reply appear on GitHub as well. If your project does not have
 this feature enabled and wishes so, or if the feature is enabled but
 not working, please contact infrastructure at
 infrastruct...@apache.org or file a JIRA ticket with INFRA.
 ---

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




 --
 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

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




-- 
===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

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

RE: [GitHub] cordova-app-hello-world pull request: CB-9009 default CSP needs to...

[Josh Soref]

https://github.com/apache/cordova-app-hello-world/pull/10#issuecomment-10142
9782

Problem:
As is, today, Cordova projects created w/ the default cordova hello-world
template which have any plugins won't work on BlackBerry 10 at-all

My fix is to add a CSP whitelist for the BlackBerry 10 magic port...

Steve Gill commented on the pull request:
 As long as this doesn't negatively impact other platforms, merge away.

The only downside is that if someone manages to have another application
running on that port on a non blackberry platform,
and if someone writes a buggy application which can be taken over,
then that buggy application could talk to the other application w/ that port
on that non blackberry platform

it's pretty obscure, but...

Are people OK with this?

The section we're changing has a bunch of platform specific notes, it seems
like it's really asking for a pre-processor of some sort to magically stitch
up this field...


Does anyone have an alternative proposal? If not, I'm planning to merge my
PR on Monday.


smime.p7s
Description: S/MIME cryptographic signature

Re: [GitHub] cordova-app-hello-world pull request: CB-9009 default CSP needs to...

[Jesse]

Can we use a plugin hook to modify the csp in the bb10 start html page?

localhost is not defined on most platforms afaik, so it may be less of an
issue.


@purplecabbage
risingj.com

On Wed, May 13, 2015 at 1:00 PM, Josh Soref jso...@blackberry.com wrote:


 https://github.com/apache/cordova-app-hello-world/pull/10#issuecomment-10142
 9782

 Problem:
 As is, today, Cordova projects created w/ the default cordova hello-world
 template which have any plugins won't work on BlackBerry 10 at-all

 My fix is to add a CSP whitelist for the BlackBerry 10 magic port...

 Steve Gill commented on the pull request:
  As long as this doesn't negatively impact other platforms, merge
 away.

 The only downside is that if someone manages to have another application
 running on that port on a non blackberry platform,
 and if someone writes a buggy application which can be taken over,
 then that buggy application could talk to the other application w/ that
 port
 on that non blackberry platform

 it's pretty obscure, but...

 Are people OK with this?

 The section we're changing has a bunch of platform specific notes, it seems
 like it's really asking for a pre-processor of some sort to magically
 stitch
 up this field...


 Does anyone have an alternative proposal? If not, I'm planning to merge my
 PR on Monday.

Re: [GitHub] cordova-wp8 pull request: Added Newtonsoft json dll

[Jesse]

That sounds like a very reasonable approach.
So we'll revert the changes to JSONHelper.cs + leave NewtonsoftJSON lib in
and plugin developers can use it if they prefer.
Sound good?

Yes, currently PG-Build supports only cordova-wp8.
Windows Universal (8.1) is in the works.



@purplecabbage
risingj.com

On Tue, May 12, 2015 at 12:31 PM, brodybits g...@git.apache.org wrote:

 Github user brodybits commented on the pull request:

 https://github.com/apache/cordova-wp8/pull/79#issuecomment-101394601

  If we can avoid the breaking change it would be better and in this
 case we have a solution that works well to avoid it
 (apache/cordova-plugin-file-transfer#72). I understand Newtonsoft JSON is a
 better API and is more efficient.

 The only real trouble spot I have seen is in the PluginResult class,
 in case a plugin returns an arbitrary data type (such as a byte array). To
 solve this, we can modify the PluginResult to use an internal function that
 uses `DataContractJsonSerializer` (along with a `StreamReader`) to convert
 the plugin result to JSON. I am happy to issue a PR for this if you need it.

 Of course, to be absolutely safe, we could revert the changes to
 `template/cordovalib/JSON/JsonHelper.cs` but keep the Newtonsoft JSON
 library for those plugins that want to use it. IMHO, it should be safe for
 this project to use the Newtonsoft JsonConvert functions in all cases
 except for PluginResult.cs. And finally document it for the plugin authors.

 An extreme solution would be to rename (or remove) the functions in
 JsonHelper.cs and change the order of the parameters in the PluginResult()
 constructor, in order to *force* the plugin authors to review and update
 their code.

   I would not expect cordova-wp8 to wither and die anytime soon.

 In addition, it is my understanding is that cordova-wp8 is (still)
 needed to support Windows Phone in PhoneGap build.


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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

Re: [GitHub] cordova-wp8 pull request: Added Newtonsoft json dll

[Jesse]

Yes, absolutely. But, this is a major version jump, so breakage IS expected.
All plugins could have issues, the first step is to properly define the
'engines' in the plugin.xml to declare what versions you work with.

@purplecabbage
risingj.com

On Wed, May 6, 2015 at 10:28 AM, brodybits g...@git.apache.org wrote:

 Github user brodybits commented on the pull request:

 https://github.com/apache/cordova-wp8/pull/79#issuecomment-99544620

  It looks like these changes brought new test failures on wp8:
  https://issues.apache.org/jira/browse/CB-8968

 @alsorokin I will take a look as well. Cannot promise I will find
 anything.



 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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

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

[Jesse]

Looking. 



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

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

RE: Github, again.

[Josh Soref]

Tony wrote:
 FWIW, I don¹t think that Cordova JIRA is horrible.
 We use JIRA at Intel and have had a lot of intermittent performance
 problems that were mostly resolved with a recent version update.
 It seems like a lot of effort has been invested in the Cordova JIRA and it
 seems (to me) like it would be a shame to move away from it.
 I¹ll leave it at that and comment on your other thread Michal.

Fwiw, we use JIRA at work, and I hate that JIRA much more than I hate
Apache's JIRA.

We also have a GitHub tracker that we use for WebWorks.
I'm not a big fan of it, but the simplicity is a nice thing relative to all
of the mandatory knobs in my least favorite JIRA.

GitHub's linking features are vaguely nice.

Note: in general, I'm a proponent of being able to review the history of
code and being able to understand why a change was made.
Traditionally, that involves looking at a bug tracker and reading the bug.

However, neither JIRAs I've mentioned today are used that way, often they're
at best Process Shepherds, and often they're just full of noise.

I don't need a Process Shepherd, and if I have to have one, I'd rather it be
Pull Requests.

A funny thing to consider in this area:

Instead of having a vote thread which people can email -- and which
frequently spirals out of control.
We could have a Vote RC file, and people could pull request their +1s.

No one in their right mind would try to add a long comment into such a vote
file.

But, we could have a discuss thread. And we could receive emails about pull
requests for the +1s.

Such a thing could be trackable, in a meaningful way...
And your commit message / pull request for a +1 could explain what you
tested.

 On the other hand (and this is the real point I wanted to make), the wiki
 is horrible.

 It is barely useable and it¹s poor performance is a major de-motivator
 when it comes to editing it.

Its performance definitely isn't a plus.

The process of managing accounts is a bumber.

I'd certainly favor a pull request model (which GitHub pages would give me).

 There are important documents and information that only exist on the wiki!
 In one of the other threads, Carlos suggested using Github wiki - it seems
 like this would be a great change to me if it is possible.
 From my perspective, this would be a far more valuable change than moving
 from JIRA to Github Issues.
 Just wanted to raise it since you seem to be interested in spinning some
 of these topics off into dedicated discussion threadsŠ

I've seen some projects try using GitHub pages, and I haven't seen many
where it works particularly well.
OTOH, I haven't seen *anything* that works particularly well.


smime.p7s
Description: S/MIME cryptographic signature

Re: Github, again.

[Brian LeRoux]

Alas, no. Vote threads MUST be an email. Our original interpretation:
tagging a release by a PMC 'platform lead' === Vote… which, some may
recall, the board did not take kindly.

Moving from code to conversation def has slowed the project cadence down.
Our last major release was July 2013. There was a significant stall in
adoption but that seems to have recovered and really put wind back in the
sails for downstreams I can measure like PhoneGap. Maybe that is ok. Def a
great conversation piece.


On Mon, Apr 13, 2015 at 3:55 PM, Josh Soref jso...@blackberry.com wrote:

 Tony wrote:
  FWIW, I don¹t think that Cordova JIRA is horrible.
  We use JIRA at Intel and have had a lot of intermittent performance
  problems that were mostly resolved with a recent version update.
  It seems like a lot of effort has been invested in the Cordova JIRA and
 it
  seems (to me) like it would be a shame to move away from it.
  I¹ll leave it at that and comment on your other thread Michal.

 Fwiw, we use JIRA at work, and I hate that JIRA much more than I hate
 Apache's JIRA.

 We also have a GitHub tracker that we use for WebWorks.
 I'm not a big fan of it, but the simplicity is a nice thing relative to all
 of the mandatory knobs in my least favorite JIRA.

 GitHub's linking features are vaguely nice.

 Note: in general, I'm a proponent of being able to review the history of
 code and being able to understand why a change was made.
 Traditionally, that involves looking at a bug tracker and reading the bug.

 However, neither JIRAs I've mentioned today are used that way, often
 they're
 at best Process Shepherds, and often they're just full of noise.

 I don't need a Process Shepherd, and if I have to have one, I'd rather it
 be
 Pull Requests.

 A funny thing to consider in this area:

 Instead of having a vote thread which people can email -- and which
 frequently spirals out of control.
 We could have a Vote RC file, and people could pull request their +1s.

 No one in their right mind would try to add a long comment into such a vote
 file.

 But, we could have a discuss thread. And we could receive emails about pull
 requests for the +1s.

 Such a thing could be trackable, in a meaningful way...
 And your commit message / pull request for a +1 could explain what you
 tested.

  On the other hand (and this is the real point I wanted to make), the wiki
  is horrible.

  It is barely useable and it¹s poor performance is a major de-motivator
  when it comes to editing it.

 Its performance definitely isn't a plus.

 The process of managing accounts is a bumber.

 I'd certainly favor a pull request model (which GitHub pages would give
 me).

  There are important documents and information that only exist on the
 wiki!
  In one of the other threads, Carlos suggested using Github wiki - it
 seems
  like this would be a great change to me if it is possible.
  From my perspective, this would be a far more valuable change than moving
  from JIRA to Github Issues.
  Just wanted to raise it since you seem to be interested in spinning some
  of these topics off into dedicated discussion threadsŠ

 I've seen some projects try using GitHub pages, and I haven't seen many
 where it works particularly well.
 OTOH, I haven't seen *anything* that works particularly well.

RE: Github, again.

[Ross Gardler (MS OPEN TECH)]

Those conversations have been had. GitHub won't open the logs (and we can't 
expect them to given the privacy implications). Feel free to discuss again if 
you like - things may have changed.

GitHub enterprise is not free. My comment about cost was from memory, I've 
asked David to remind me of the details.

Ross

-Original Message-
From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian 
LeRoux
Sent: Friday, April 10, 2015 12:17 PM
To: dev@cordova.apache.org
Subject: Re: Github, again.

being donated my guess the cost was installation and maintenance? anyhow, now 
that the goal posts have been moved to logs I'm fairly certain they'd open 
those to us as well (I'll find out)

On Fri, Apr 10, 2015 at 9:02 AM, Ross Gardler (MS OPEN TECH)  
ross.gard...@microsoft.com wrote:

 Yes we have discussed this. The cost is prohibitive. David Nalley as 
 VP Infra has the details.

 Sent from my Windows Phone
 
 From: Brian LeRouxmailto:b...@brian.io
 Sent: ‎4/‎10/‎2015 8:53 AM
 To: dev@cordova.apache.orgmailto:dev@cordova.apache.org
 Subject: Re: Github, again.

 And actually, a colleague recalled we talked about on prem w github 
 entp too. Which totally addresses the issue. It was shot down of 
 course despite github offering to donate to apache.

 Now maybe this is possible?

 On Fri, Apr 10, 2015, 8:16 AM Brian LeRoux b...@brian.io wrote:

  I said as much Jim. As to FUD...
 
  On Fri, Apr 10, 2015, 6:18 AM Jim Jagielski j...@jagunet.com wrote:
 
  Actually, during the long discussion regarding Groovy moving to the 
  ASF, the whole what's wrong w/ Github was brought up several 
  times, and answered several times (as I was almost sure it was done 
  here)... In any case, the following is a typical response to why 
  Github cannot be canon:
 
  
  http://groovy.329449.n5.nabble.com/Moving-Groovy-to-a-Founda
  tion-tp5722483p5722847.html
 
  Since IP provenance is important, I'm sure we all understand this 
  issue now, and this FUD can finally die.
 
   On Apr 9, 2015, at 8:27 PM, Brian LeRoux b...@brian.io wrote:
  
   It is the current interpretation of policy wrt providence of the 
   IP
  (code).
   Github could go bankrupt/exit to Oracle and disappear (ala Google
 Code)
  or
   worse go rogue and sneak patent violations into our code.
  
   I'll leave the likelyhood of these scare scenarios to you noting 
   that
  most
   brands appear to feel this risk is low.
  
   On Thu, Apr 9, 2015, 5:22 PM Gorkem Ercan 
   gorkem.er...@gmail.com
  wrote:
  
  
  
   On 9 Apr 2015, at 15:38, Andrew Grieve wrote:
  
   Apache provides a lot of benefit. I don't want elaborate right 
   now, but I will promise to post back with some formulated 
   thoughts a bit later (some of this I'm prepping for my 
   ApacheCon talk, so I need to do it anyways).
  
   Joe - Please please *please* do not write emails that are not 
   constructive.
   If you want to be negative, don't hit the send button. If not 
   for
 the
   sake
   of others, for the sake of yourself - saying negative things 
   about others almost always ends up making you look worse than 
   those you are being negative towards.
  
   Another angle:
   Even if you are convinced that you're right, and even though 
   your views are your own (although statements like Or we could 
   just leave the ASF
   make it
   sound like you are representing more than that), your tone 
   often
 just
   makes
   people want to run away rather than engage. Would you want to 
   contribute to a project that is full of smileys and 
   encouragement, or one where people are negative and abrasive? 
   It really goes a long way to keep the
 email
   tone
   positive even when you disagree.
  
   Since I've been on this project, I've felt that non-Cordova
 Apache'ers
   (we
   are apache'ers too remember) have been constructive and helpful:
   - We want a VM. Mike Billau reached out, and INFRA helped us 
   set one up.
   - We want to do BuildBot. Infra helped get us going on their 
   shared instance.
   - We want to use git. So do other projects, and it has been a 
   collaboration between Infra and other projects that made it 
   happen (we complained, but didn't do the work to make it 
   possible).
   - We want to try reviewboard - Infra got us going in no time
 (although
   we
   decided not to stick with it).
  
   Why can we not use Github issues?
   - It's certainly *not* the case that Apache hates github.
   - Has anyone even thought to ask? Maybe it's just a 
   conversation
 that
   hasn't happened yet.
   - It's important that Apache projects host their own data, but 
   do issue trackers count as data?
  
   This may actually be intellectual property related. Eclipse
 foundation
   which allows GitHub to be used as primary SCM, does not allow 
   GitHub as issue tracker because it can not be covered by the 
   Eclipse.org
 terms
   of use.
  
   - Sounds like a *great* discussion to have.
   - d

Re: [GitHub] cordova-plugin-splashscreen pull request: CB-8753 Maintain splash ...

[Jesse]

Some devices have had a flicker issue, not sure which it was.
Joe might remember.

@purplecabbage
risingj.com

On Mon, Mar 30, 2015 at 6:17 PM, AlexTalis g...@git.apache.org wrote:

 Github user AlexTalis commented on a diff in the pull request:


 https://github.com/apache/cordova-plugin-splashscreen/pull/43#discussion_r27446641

 --- Diff: src/android/SplashScreen.java ---
 @@ -194,9 +263,25 @@ public void run() {
  // TODO: Use the background color of the webView's
 parent instead of using the
  // preference.

  root.setBackgroundColor(preferences.getInteger(backgroundColor,
 Color.BLACK));
 +
  root.setLayoutParams(new
 LinearLayout.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,
  ViewGroup.LayoutParams.MATCH_PARENT, 0.0F));
 -root.setBackgroundResource(drawableId);
 +
 +// Use an ImageView to render the image because of
 its flexible scaling options.
 +splashImageView = new ImageView(context);
 +splashImageView.setImageResource(drawableId);
 --- End diff --

 Do you know of any other reason for setting this background color? If
 not, then I think we can take out Linear Layout.


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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

Re: [GitHub] cordova-wp8 pull request: JsonHelper testing, and use of Newtonsof...

[Jesse]

We have to evaluate if including Newtonsoft's library is a) legal, b) worth
it
Truthfully, the library itself is bigger than cordova-wp8, so this is a
non-starter for me, which is why I haven't pulled this in.

@purplecabbage
risingj.com

On Thu, Mar 19, 2015 at 9:17 AM, mowcixo g...@git.apache.org wrote:

 Github user mowcixo commented on the pull request:

 https://github.com/apache/cordova-wp8/pull/62#issuecomment-83647420

 @vladimir-kotikov it uses a .gitmodule to do that... I don't know if
 it is the best way. How do you recommend to do that? Using the .dll
 directly?


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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

RE: [GitHub] cordova-lib pull request: CB-8703: Add support for semver and devi...

[Tim Barham]

Jesse - we couldn't use `target` for `config-file`, because there was already 
a `target` attribute that had a different meaning. So it was decided to go with 
`device-target`. I requested Rob change the equivalent `target` attribute on 
`framework` and `lib-file` so that it was consistent across elements.
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [GitHub] cordova-plugin-file-transfer pull request: Fix NoSuchMethodExcepti...

[Darryl Pogue]

On 16 March 2015 at 22:54, Jesse purplecabb...@gmail.com wrote:
 They are independent no?
 Is this plugin relying on cordova-android 4.0? Or vice versa

The plugin doesn't rely on cordova-android 4.0, but this change fixes
a crash on Android 4.0-4.3 when using File Transfer and Crosswalk
together (which is the big feature for cordova-android 4.0).

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

Re: [GitHub] cordova-plugin-file-transfer pull request: Fix NoSuchMethodExcepti...

[Carlos Santana]

Where is the JIRA #?

On Tue, Mar 17, 2015 at 2:46 AM, Darryl Pogue dvpdin...@gmail.com wrote:

 On 16 March 2015 at 22:54, Jesse purplecabb...@gmail.com wrote:
  They are independent no?
  Is this plugin relying on cordova-android 4.0? Or vice versa

 The plugin doesn't rely on cordova-android 4.0, but this change fixes
 a crash on Android 4.0-4.3 when using File Transfer and Crosswalk
 together (which is the big feature for cordova-android 4.0).

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




-- 
Carlos Santana
csantan...@gmail.com

Re: [GitHub] cordova-plugin-file-transfer pull request: Fix NoSuchMethodExcepti...

[Jesse]

They are independent no?
Is this plugin relying on cordova-android 4.0? Or vice versa 



 On Mar 16, 2015, at 8:39 PM, dpogue g...@git.apache.org wrote:
 
 Github user dpogue commented on the pull request:
 

 https://github.com/apache/cordova-plugin-file-transfer/pull/68#issuecomment-82073797
 
/cc @agrieve 
Would be good to get this in before cordova-android 4.0.0 release.
 
 
 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org
 

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

RE: [GitHub] cordova-windows pull request: Fix for callback invocation with NO_...

[Rob Paveza]

Only question is if callback.status might be undefined (stands to reason if it 
can be null).  If so, the present check is insufficient and changes because you 
test with ===.

-Rob

-Original Message-
From: robpaveza [mailto:g...@git.apache.org] 
Sent: Wednesday, March 11, 2015 11:14 PM
To: dev@cordova.apache.org
Subject: [GitHub] cordova-windows pull request: Fix for callback invocation 
with NO_...

Github user robpaveza commented on a diff in the pull request:

https://github.com/apache/cordova-windows/pull/61#discussion_r26280733
  
--- Diff: cordova-js-src/exec.js ---
@@ -60,18 +60,32 @@ module.exports = function (success, fail, service, 
action, args) {
 // CB-5806 [Windows8] Add keepCallback support to proxy
 onSuccess = function (result, callbackOptions) {
 callbackOptions = callbackOptions || {};
+var callbackStatus;
+if (callbackOptions.status !== null) {
--- End diff --

Is undefined a possible value here?


---
If your project is set up for it, you can reply to this email and have your 
reply appear on GitHub as well. If your project does not have this feature 
enabled and wishes so, or if the feature is enabled but not working, please 
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with 
INFRA.
---

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


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

RE: [GitHub] cordova-firefoxos pull request: CB-7567 Don't use adm-zip because

[Jon Buckley]

Hello Apache Cordova devs! I've submitted a patch (
https://github.com/apache/cordova-firefoxos/pull/22 ) to fix
https://issues.apache.org/jira/browse/CB-7567 . I've emailed my ICLA in,
so I'm wondering what the next step is? Could I get a review from
someone?

Thanks, Jon

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

Re: [GitHub] cordova-lib pull request: CB-8420 'cordova plugin add' should retr...

[Andrew Grieve]

ah, I missed that lstatSync throws an exception for non-string args. I
suppose that's fine. Will merge!


On Wed, Feb 11, 2015 at 2:54 PM, omefire g...@git.apache.org wrote:

 Github user omefire commented on a diff in the pull request:

 https://github.com/apache/cordova-lib/pull/162#discussion_r24527527

 --- Diff: cordova-lib/src/cordova/plugin.js ---
 @@ -114,6 +116,22 @@ module.exports = function plugin(command,
 targets, opts) {
  target = target.substring(0,
 target.length - 1);
  }

 +var parts = target.split('@');
 +var id = parts[0];
 +var version = parts[1];
 +
 +// If no version is specified, retrieve the
 version from config.xml
 +if(!version  !cordova_util.isUrl(id) 
 !cordova_util.isDirectory(id)){
 +events.emit('verbose', 'no version
 specified, retrieving version from config.xml');
 +var ver = getVersionFromConfigFile(id,
 cfg);
 +
 +if( cordova_util.isUrl(ver) ||
 cordova_util.isDirectory(ver) ){
 --- End diff --

 @agrieve, isDirectory does handle the null/undefined cases. I just
 tested it. Am I missing something ?


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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

Re: [GitHub] cordova-wp8 pull request: CB-8412

[Jesse]

http://www.appveyor.com/docs/installed-software

@purplecabbage
risingj.com

On Fri, Feb 6, 2015 at 1:28 AM, muratsu g...@git.apache.org wrote:

 Github user muratsu commented on the pull request:

 https://github.com/apache/cordova-wp8/pull/75#issuecomment-73209662

 On build 103 you can see this error message:
 https://ci.appveyor.com/project/Humbedooh/cordova-wp8/build/1.0.103
 In order to see the failure, you have to pipe build output to test
 output, which is not desirable under normal circumstances - that's why I've
 changed it back to silent and it's not visible on 104.


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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

Re: [GitHub] cordova-plugin-device pull request: Fixes a syntax error introduce...

[Jesse]

oops, thank you!

@purplecabbage
risingj.com

On Wed, Feb 4, 2015 at 5:47 PM, nikhilkh g...@git.apache.org wrote:

 Github user nikhilkh commented on the pull request:


 https://github.com/apache/cordova-plugin-device/pull/30#issuecomment-72979743

 @purplecabbage  - Can you please commit this? This is breaking our
 medic setup.


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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

RE: [GitHub] cordova-coho pull request: CB-8375 Improve windows support for for...

[Murat Sutunc]

Can someone take a look at this PR? 

Thanks,
Murat

-Original Message-
From: muratsu [mailto:g...@git.apache.org] 
Sent: Wednesday, January 28, 2015 3:57 PM
To: dev@cordova.apache.org
Subject: [GitHub] cordova-coho pull request: CB-8375 Improve windows support 
for for...

GitHub user muratsu opened a pull request:

https://github.com/apache/cordova-coho/pull/62

CB-8375 Improve windows support for for-each

This improvement makes coho for-each work on Windows without issues. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-coho CB-8375

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-coho/pull/62.patch

To close this pull request, make a commit to your master/trunk branch with (at 
least) the following in the commit message:

This closes #62


commit d1d8d687430292afd85e79a584f618cd28e265a8
Author: Murat Sutunc mura...@microsoft.com
Date:   2015-01-28T23:56:09Z

CB-8375 Improve windows support for for-each




---
If your project is set up for it, you can reply to this email and have your 
reply appear on GitHub as well. If your project does not have this feature 
enabled and wishes so, or if the feature is enabled but not working, please 
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with 
INFRA.
---

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


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

RE: [GitHub] cordova-lib pull request: CB-8123 Plugin references can target spe...

[Tim Barham]

Thanks Jesse. Do you have any thoughts on the test failures? The failures 
appear to be related to my directory renaming - but the tests pass locally, and 
the commits look good (and identical to what I have locally).

-Original Message-
From: purplecabbage [mailto:g...@git.apache.org] 
Sent: Wednesday, January 28, 2015 12:18 PM
To: dev@cordova.apache.org
Subject: [GitHub] cordova-lib pull request: CB-8123 Plugin references can 
target spe...

Github user purplecabbage commented on the pull request:

https://github.com/apache/cordova-lib/pull/155#issuecomment-71907847
  
Very cool Tim!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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


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