[GitHub] filmaj commented on issue #399: CB-12730: Compat - INTEGRATE

[git]

filmaj commented on issue #399: CB-12730: Compat - INTEGRATE
URL: https://github.com/apache/cordova-android/pull/399#issuecomment-320116296
 
 
   Sounds like lazy consensus on the tests is "nah"
 

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

[GitHub] filmaj commented on issue #389: CB-11244: Studio Project Compatibility: Now with merge commit

[git]

filmaj commented on issue #389: CB-11244: Studio Project Compatibility: Now 
with merge commit
URL: https://github.com/apache/cordova-android/pull/389#issuecomment-320108011
 
 
   
https://github.com/infil00p/cordova-android/blob/StudioProjectCompat/bin/templates/cordova/lib/prepare.js#L214-L216
 

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

[GitHub] macdonst commented on issue #399: CB-12730: Compat - INTEGRATE

[git]

macdonst commented on issue #399: CB-12730: Compat - INTEGRATE
URL: https://github.com/apache/cordova-android/pull/399#issuecomment-320087845
 
 
   @infil00p I was thinking testing for this would be handled at the plugin 
level as it is what is requesting the permissions. Hard to instrument these 
dialogs.
 

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

[GitHub] infil00p commented on issue #389: CB-11244: Studio Project Compatibility: Now with merge commit

[git]

infil00p commented on issue #389: CB-11244: Studio Project Compatibility: Now 
with merge commit
URL: https://github.com/apache/cordova-android/pull/389#issuecomment-320080278
 
 
   @dpogue No, that's definitely a bug.  Only the app directory should exist, 
and it's clear that something else is copying over MainActivity.
 

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

[GitHub] dpogue commented on issue #389: CB-11244: Studio Project Compatibility: Now with merge commit

[git]

dpogue commented on issue #389: CB-11244: Studio Project Compatibility: Now 
with merge commit
URL: https://github.com/apache/cordova-android/pull/389#issuecomment-320067936
 
 
   So I ran this branch with the following:
   ```
   cordova create androidTest
   cd ./androidTest
   cordova platform add 
git://github.com/infil00p/cordova-android.git#StudioProjectCompat
   ```
   
   In my platforms/android I ended up with both an app folder and a src folder, 
and I have a MainActivity.java in both. Is that expected?
   ```
   android
   ??? app
   ??? ??? src
   ??? ??? main
   ??? ??? java
   ???  ?? ??? io
   ???  ??  ?? ??? cordova
   ???  ??  ?? ??? hellocordova
   ???  ??  ?? ??? MainActivity.java
   ??? src
   ??? io
   ??? cordova
   ??? hellocordova
   ??? MainActivity.java
   ```
 

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

[GitHub] cordova-plugin-file pull request #214: CB-12895 : Setup eslint and removed j...

[audreyso]

GitHub user audreyso opened a pull request:

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

CB-12895 : Setup eslint and removed jshint



### Platforms affected


### What does this PR do?
Setup eslint and removed jshint

### What testing has been done on this change?


### Checklist
- [X] [Reported an issue](http://cordova.apache.org/contribute/issues.html) 
in the JIRA database
- [X] Commit message follows the format: "CB-3232: (android) Fix bug with 
resolving file paths", where CB- is the JIRA ID & "android" is the platform 
affected.
- [X] Added automated test coverage as appropriate for this change.


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

$ git pull https://github.com/audreyso/cordova-plugin-file CB-12895

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

https://github.com/apache/cordova-plugin-file/pull/214.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 #214


commit c307226bb317f69a8df93688a6c2d71aa53fe37f
Author: Audrey So 
Date:   2017-06-09T23:06:08Z

CB-12895 : setup eslint and took out jshint




---
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: [DISCUSS] Moving JIRA issues to Github

[Filip Maj]

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

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

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

[GitHub] cordova-plugin-geolocation pull request #92: CB-12895 : Added eslint and rem...

[audreyso]

GitHub user audreyso opened a pull request:

https://github.com/apache/cordova-plugin-geolocation/pull/92

CB-12895 : Added eslint and removed jshint



### Platforms affected


### What does this PR do?
Added eslint and removed jshint

### What testing has been done on this change?


### Checklist
- [X] [Reported an issue](http://cordova.apache.org/contribute/issues.html) 
in the JIRA database
- [X] Commit message follows the format: "CB-3232: (android) Fix bug with 
resolving file paths", where CB- is the JIRA ID & "android" is the platform 
affected.
- [X] Added automated test coverage as appropriate for this change.


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

$ git pull https://github.com/audreyso/cordova-plugin-geolocation CB-12895

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

https://github.com/apache/cordova-plugin-geolocation/pull/92.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 #92


commit 69eb5ba5b5e801c55661dd277a2dd6997ff19c4d
Author: Audrey So 
Date:   2017-06-12T17:18:43Z

CB-12895 : added eslint and removed jshint




---
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: [DISCUSS] Moving JIRA issues to Github

[Jan Piotrowski]

> What about security issues?
> Right now on jira we have private security issues not visible for the regular 
> people and as far as I know, we can't do that on GitHub

Initial idea: Have an email address where people can send messages to,
the recipient then creates an issue on a private Github repo for
further talking about it.
You could probably also create a public form that does the same job of
the email address and person creating the ticket automatically if too
much effort and needed too often.
(But maybe there is a better solution, one could investigate how other
Github based projects do that)

-J

2017-08-03 11:55 GMT+02:00 julio cesar sanchez :
> What about security issues?
>
> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski"  escribió:
>
>> >> As a user, I’ll occasionally skim the recently opened bugs in Jira
>> across the entire project to see if any may affect us. Is there going to be
>> a way to do this with Github? Subscribing to notifications could be a
>> work-around but it’s not ideal.
>> >
>> > Good question. I can't really think of a way to do this...
>>
>> Github doesn't offer this out of the box (besides watching all repos
>> yourself, which comes with its own challenges). But Github has an API,
>> I am pretty sure someone already wrote something that combines issues
>> of several repos into one interface to look at, then links to the
>> individual issues (If not, it wouldn't be too much work to create
>> something like that) (Could become the new issues.cordova.io maybe?).
>> Would this fulfill your use case?
>>
>> -J
>>
>> 2017-08-03 3:13 GMT+02:00 Filip Maj :
>> >> Since it looks like not all repositories will be migrated where should
>> their issues go?
>> >
>> > All repositories will be migrated.
>> >
>> >> What about issues for repositories that don’t yet exist
>> >
>> > Can you give me an example?
>> >
>> >> or cross-cutting issues?
>> >
>> > I think if you absolutely need issues related to multiple repos, you
>> > can always create multiple issues in all relevant repos and
>> > cross-reference them.
>> >
>> >> As a user, I’ll occasionally skim the recently opened bugs in Jira
>> across the entire project to see if any may affect us. Is there going to be
>> a way to do this with Github? Subscribing to notifications could be a
>> work-around but it’s not ideal.
>> >
>> > Good question. I can't really think of a way to do this...
>> >
>> >> Are we going to get more high quality bug reports using Github? This
>> may not be answerable without trying it out, but making issues easier to
>> create issues could cause an influx of questions and non-cordova related
>> bugs. This could add on to the difficulties of triaging and migrating bugs
>> across repos.
>> >
>> > To be fair, we already get painful triage-work via GitHub just by
>> > opening up Pull Requests to the public. People will use those to post
>> > questions or issues, because they are unaware that there are other
>> > support and issue filing avenues (they will mask them as PRs merging a
>> > release branch into master). At least those people now have a more
>> > obvious place to file issues: the Issues section on GitHub. We already
>> > have a lot of triage work on JIRA as it is. I doubt this will go down.
>> > That said, I don't think that's necessarily bad. Will we have more
>> > work? Probably. Will we be able to more easily identify issues, and
>> > earlier, and generally be also more accessible to our community? I
>> > would think yes. Double-edged sword. I say let's see how it goes.
>> >
>> >> If we migrate before triaging where will all the un-triaged issues end
>> up?
>> >
>> > They would end up in GitHub, at which point we'd triage them within
>> GitHub.
>> >
>> >> Also if we enable Github issues before phase 2 are we going to be using
>> both Jira and Github Issues for a period of time?
>> >
>> > Yes.
>> >
>> > Different topic: Shaz, based on your INFRA ticket / phase breakdown,
>> > the implication is that there will be leftover cordova repos in Apache
>> > Git (cordova-medic, weinre, deprecated platforms / plugins). What do
>> > we do with those? Separate discussion?
>> >
>> > On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson  wrote:
>> >> I have a few questions about moving issues to GitHub. I haven’t used
>> Github
>> >> issues much so these all may be easily solvable.
>> >>
>> >> * Since it looks like not all repositories will be migrated where should
>> >> their issues go? What about issues for repositories that don’t yet
>> exist or
>> >> cross-cutting issues?
>> >> * As a user, I’ll occasionally skim the recently opened bugs in Jira
>> across
>> >> the entire project to see if any may affect us. Is there going to be a
>> way
>> >> to do this with Github? Subscribing to notifications could be a
>> work-around
>> >> but it’s not ideal.
>> >> * Are we going to get more high quality bug reports using Github? This
>> may
>> >> not be 

Re: [DISCUSS] Moving JIRA issues to Github

[Connor Pearson]

I think the web interface is a good idea. It might help triage as well if
you're able to search and filter issues across the entire project. I think
it might need to have some mechanism for excluding or grouping migrated
issues too.

On Thu, Aug 3, 2017 at 5:55 AM, julio cesar sanchez 
wrote:

> What about security issues?
>
> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" 
> escribió:
>
> > >> As a user, I’ll occasionally skim the recently opened bugs in Jira
> > across the entire project to see if any may affect us. Is there going to
> be
> > a way to do this with Github? Subscribing to notifications could be a
> > work-around but it’s not ideal.
> > >
> > > Good question. I can't really think of a way to do this...
> >
> > Github doesn't offer this out of the box (besides watching all repos
> > yourself, which comes with its own challenges). But Github has an API,
> > I am pretty sure someone already wrote something that combines issues
> > of several repos into one interface to look at, then links to the
> > individual issues (If not, it wouldn't be too much work to create
> > something like that) (Could become the new issues.cordova.io maybe?).
> > Would this fulfill your use case?
> >
> > -J
> >
> > 2017-08-03 3:13 GMT+02:00 Filip Maj :
> > >> Since it looks like not all repositories will be migrated where should
> > their issues go?
> > >
> > > All repositories will be migrated.
> > >
> > >> What about issues for repositories that don’t yet exist
> > >
> > > Can you give me an example?
> > >
> > >> or cross-cutting issues?
> > >
> > > I think if you absolutely need issues related to multiple repos, you
> > > can always create multiple issues in all relevant repos and
> > > cross-reference them.
> > >
> > >> As a user, I’ll occasionally skim the recently opened bugs in Jira
> > across the entire project to see if any may affect us. Is there going to
> be
> > a way to do this with Github? Subscribing to notifications could be a
> > work-around but it’s not ideal.
> > >
> > > Good question. I can't really think of a way to do this...
> > >
> > >> Are we going to get more high quality bug reports using Github? This
> > may not be answerable without trying it out, but making issues easier to
> > create issues could cause an influx of questions and non-cordova related
> > bugs. This could add on to the difficulties of triaging and migrating
> bugs
> > across repos.
> > >
> > > To be fair, we already get painful triage-work via GitHub just by
> > > opening up Pull Requests to the public. People will use those to post
> > > questions or issues, because they are unaware that there are other
> > > support and issue filing avenues (they will mask them as PRs merging a
> > > release branch into master). At least those people now have a more
> > > obvious place to file issues: the Issues section on GitHub. We already
> > > have a lot of triage work on JIRA as it is. I doubt this will go down.
> > > That said, I don't think that's necessarily bad. Will we have more
> > > work? Probably. Will we be able to more easily identify issues, and
> > > earlier, and generally be also more accessible to our community? I
> > > would think yes. Double-edged sword. I say let's see how it goes.
> > >
> > >> If we migrate before triaging where will all the un-triaged issues end
> > up?
> > >
> > > They would end up in GitHub, at which point we'd triage them within
> > GitHub.
> > >
> > >> Also if we enable Github issues before phase 2 are we going to be
> using
> > both Jira and Github Issues for a period of time?
> > >
> > > Yes.
> > >
> > > Different topic: Shaz, based on your INFRA ticket / phase breakdown,
> > > the implication is that there will be leftover cordova repos in Apache
> > > Git (cordova-medic, weinre, deprecated platforms / plugins). What do
> > > we do with those? Separate discussion?
> > >
> > > On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson 
> wrote:
> > >> I have a few questions about moving issues to GitHub. I haven’t used
> > Github
> > >> issues much so these all may be easily solvable.
> > >>
> > >> * Since it looks like not all repositories will be migrated where
> should
> > >> their issues go? What about issues for repositories that don’t yet
> > exist or
> > >> cross-cutting issues?
> > >> * As a user, I’ll occasionally skim the recently opened bugs in Jira
> > across
> > >> the entire project to see if any may affect us. Is there going to be a
> > way
> > >> to do this with Github? Subscribing to notifications could be a
> > work-around
> > >> but it’s not ideal.
> > >> * Are we going to get more high quality bug reports using Github? This
> > may
> > >> not be answerable without trying it out, but making issues easier to
> > create
> > >> issues could cause an influx of questions and non-cordova related
> bugs.
> > >> This could add on to the difficulties of triaging and migrating bugs
> > across
> > >> repos.
> > >> 

Re: [DISCUSS] Moving JIRA issues to Github

[julio cesar sanchez]

What about security issues?

El 3 ago. 2017 4:53 a. m., "Jan Piotrowski"  escribió:

> >> As a user, I’ll occasionally skim the recently opened bugs in Jira
> across the entire project to see if any may affect us. Is there going to be
> a way to do this with Github? Subscribing to notifications could be a
> work-around but it’s not ideal.
> >
> > Good question. I can't really think of a way to do this...
>
> Github doesn't offer this out of the box (besides watching all repos
> yourself, which comes with its own challenges). But Github has an API,
> I am pretty sure someone already wrote something that combines issues
> of several repos into one interface to look at, then links to the
> individual issues (If not, it wouldn't be too much work to create
> something like that) (Could become the new issues.cordova.io maybe?).
> Would this fulfill your use case?
>
> -J
>
> 2017-08-03 3:13 GMT+02:00 Filip Maj :
> >> Since it looks like not all repositories will be migrated where should
> their issues go?
> >
> > All repositories will be migrated.
> >
> >> What about issues for repositories that don’t yet exist
> >
> > Can you give me an example?
> >
> >> or cross-cutting issues?
> >
> > I think if you absolutely need issues related to multiple repos, you
> > can always create multiple issues in all relevant repos and
> > cross-reference them.
> >
> >> As a user, I’ll occasionally skim the recently opened bugs in Jira
> across the entire project to see if any may affect us. Is there going to be
> a way to do this with Github? Subscribing to notifications could be a
> work-around but it’s not ideal.
> >
> > Good question. I can't really think of a way to do this...
> >
> >> Are we going to get more high quality bug reports using Github? This
> may not be answerable without trying it out, but making issues easier to
> create issues could cause an influx of questions and non-cordova related
> bugs. This could add on to the difficulties of triaging and migrating bugs
> across repos.
> >
> > To be fair, we already get painful triage-work via GitHub just by
> > opening up Pull Requests to the public. People will use those to post
> > questions or issues, because they are unaware that there are other
> > support and issue filing avenues (they will mask them as PRs merging a
> > release branch into master). At least those people now have a more
> > obvious place to file issues: the Issues section on GitHub. We already
> > have a lot of triage work on JIRA as it is. I doubt this will go down.
> > That said, I don't think that's necessarily bad. Will we have more
> > work? Probably. Will we be able to more easily identify issues, and
> > earlier, and generally be also more accessible to our community? I
> > would think yes. Double-edged sword. I say let's see how it goes.
> >
> >> If we migrate before triaging where will all the un-triaged issues end
> up?
> >
> > They would end up in GitHub, at which point we'd triage them within
> GitHub.
> >
> >> Also if we enable Github issues before phase 2 are we going to be using
> both Jira and Github Issues for a period of time?
> >
> > Yes.
> >
> > Different topic: Shaz, based on your INFRA ticket / phase breakdown,
> > the implication is that there will be leftover cordova repos in Apache
> > Git (cordova-medic, weinre, deprecated platforms / plugins). What do
> > we do with those? Separate discussion?
> >
> > On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson  wrote:
> >> I have a few questions about moving issues to GitHub. I haven’t used
> Github
> >> issues much so these all may be easily solvable.
> >>
> >> * Since it looks like not all repositories will be migrated where should
> >> their issues go? What about issues for repositories that don’t yet
> exist or
> >> cross-cutting issues?
> >> * As a user, I’ll occasionally skim the recently opened bugs in Jira
> across
> >> the entire project to see if any may affect us. Is there going to be a
> way
> >> to do this with Github? Subscribing to notifications could be a
> work-around
> >> but it’s not ideal.
> >> * Are we going to get more high quality bug reports using Github? This
> may
> >> not be answerable without trying it out, but making issues easier to
> create
> >> issues could cause an influx of questions and non-cordova related bugs.
> >> This could add on to the difficulties of triaging and migrating bugs
> across
> >> repos.
> >> * If we migrate before triaging where will all the un-triaged issues end
> >> up? Also if we enable Github issues before phase 2 are we going to be
> using
> >> both Jira and Github Issues for a period of time?
> >>
> >> -Connor
> >>
> >>
> >> On August 2, 2017 at 7:08:18 PM, Jan Piotrowski (piotrow...@gmail.com)
> >> wrote:
> >>
> >> If people post their issue at the wrong repo (which of course can and
> >> will happen from time to time), there is a way to move them over with
> >> minimal loss of information:
> >>
> >> 

Re: [DISCUSS] Moving JIRA issues to Github

[Jan Piotrowski]

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

Github doesn't offer this out of the box (besides watching all repos
yourself, which comes with its own challenges). But Github has an API,
I am pretty sure someone already wrote something that combines issues
of several repos into one interface to look at, then links to the
individual issues (If not, it wouldn't be too much work to create
something like that) (Could become the new issues.cordova.io maybe?).
Would this fulfill your use case?

-J

2017-08-03 3:13 GMT+02:00 Filip Maj :
>> Since it looks like not all repositories will be migrated where should their 
>> issues go?
>
> All repositories will be migrated.
>
>> What about issues for repositories that don’t yet exist
>
> Can you give me an example?
>
>> or cross-cutting issues?
>
> I think if you absolutely need issues related to multiple repos, you
> can always create multiple issues in all relevant repos and
> cross-reference them.
>
>> As a user, I’ll occasionally skim the recently opened bugs in Jira across 
>> the entire project to see if any may affect us. Is there going to be a way 
>> to do this with Github? Subscribing to notifications could be a work-around 
>> but it’s not ideal.
>
> Good question. I can't really think of a way to do this...
>
>> Are we going to get more high quality bug reports using Github? This may not 
>> be answerable without trying it out, but making issues easier to create 
>> issues could cause an influx of questions and non-cordova related bugs. This 
>> could add on to the difficulties of triaging and migrating bugs across repos.
>
> To be fair, we already get painful triage-work via GitHub just by
> opening up Pull Requests to the public. People will use those to post
> questions or issues, because they are unaware that there are other
> support and issue filing avenues (they will mask them as PRs merging a
> release branch into master). At least those people now have a more
> obvious place to file issues: the Issues section on GitHub. We already
> have a lot of triage work on JIRA as it is. I doubt this will go down.
> That said, I don't think that's necessarily bad. Will we have more
> work? Probably. Will we be able to more easily identify issues, and
> earlier, and generally be also more accessible to our community? I
> would think yes. Double-edged sword. I say let's see how it goes.
>
>> If we migrate before triaging where will all the un-triaged issues end up?
>
> They would end up in GitHub, at which point we'd triage them within GitHub.
>
>> Also if we enable Github issues before phase 2 are we going to be using both 
>> Jira and Github Issues for a period of time?
>
> Yes.
>
> Different topic: Shaz, based on your INFRA ticket / phase breakdown,
> the implication is that there will be leftover cordova repos in Apache
> Git (cordova-medic, weinre, deprecated platforms / plugins). What do
> we do with those? Separate discussion?
>
> On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson  wrote:
>> I have a few questions about moving issues to GitHub. I haven’t used Github
>> issues much so these all may be easily solvable.
>>
>> * Since it looks like not all repositories will be migrated where should
>> their issues go? What about issues for repositories that don’t yet exist or
>> cross-cutting issues?
>> * As a user, I’ll occasionally skim the recently opened bugs in Jira across
>> the entire project to see if any may affect us. Is there going to be a way
>> to do this with Github? Subscribing to notifications could be a work-around
>> but it’s not ideal.
>> * Are we going to get more high quality bug reports using Github? This may
>> not be answerable without trying it out, but making issues easier to create
>> issues could cause an influx of questions and non-cordova related bugs.
>> This could add on to the difficulties of triaging and migrating bugs across
>> repos.
>> * If we migrate before triaging where will all the un-triaged issues end
>> up? Also if we enable Github issues before phase 2 are we going to be using
>> both Jira and Github Issues for a period of time?
>>
>> -Connor
>>
>>
>> On August 2, 2017 at 7:08:18 PM, Jan Piotrowski (piotrow...@gmail.com)
>> wrote:
>>
>> If people post their issue at the wrong repo (which of course can and
>> will happen from time to time), there is a way to move them over with
>> minimal loss of information:
>>
>> https://github.com/ionic-team/ionic/issues/12542
>> https://github.com/ionic-team/ionic-cli/issues/2597
>>
>> This works for issues where several people replied already in the
>> exact same way:
>>
>> https://github.com/ionic-team/ionic/issues/11898
>>