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

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

On Thu, Aug 3, 2017 at 4:30 AM, Jan Piotrowski <piotrow...@gmail.com> wrote:
>> What about security issues?
>> Right now on jira we have private security issues not visible for the 
>> regular people and as far as I know, we can't do that on GitHub
>
> Initial idea: Have an email address where people can send messages to,
> the recipient then creates an issue on a private Github repo for
> further talking about it.
> You could probably also create a public form that does the same job of
> the email address and person creating the ticket automatically if too
> much effort and needed too often.
> (But maybe there is a better solution, one could investigate how other
> Github based projects do that)
>
> -J
>
> 2017-08-03 11:55 GMT+02:00 julio cesar sanchez <jcesarmob...@gmail.com>:
>> What about security issues?
>>
>> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <piotrow...@gmail.com> escribió:
>>
>>> >> As a user, I’ll occasionally skim the recently opened bugs in Jira
>>> across the entire project to see if any may affect us. Is there going to be
>>> a way to do this with Github? Subscribing to notifications could be a
>>> work-around but it’s not ideal.
>>> >
>>> > Good question. I can't really think of a way to do this...
>>>
>>> Github doesn't offer this out of the box (besides watching all repos
>>> yourself, which comes with its own challenges). But Github has an API,
>>> I am pretty sure someone already wrote something that combines issues
>>> of several repos into one interface to look at, then links to the
>>> individual issues (If not, it wouldn't be too much work to create
>>> something like that) (Could become the new issues.cordova.io maybe?).
>>> Would this fulfill your use case?
>>>
>>> -J
>>>
>>> 2017-08-03 3:13 GMT+02:00 Filip Maj <maj....@gmail.com>:
>>> >> Since it looks like not all repositories will be migrated where should
>>> their issues go?
>>> >
>>> > All repositories will be migrated.
>>> >
>>> >> What about issues for repositories that don’t yet exist
>>> >
>>> > Can you give me an example?
>>> >
>>> >> or cross-cutting issues?
>>> >
>>> > I think if you absolutely need issues related to multiple repos, you
>>> > can always create multiple issues in all relevant repos and
>>> > cross-reference them.
>>> >
>>> >> As a user, I’ll occasionally skim the recently opened bugs in Jira
>>> across the entire project to see if any may affect us. Is there going to be
>>> a way to do this with Github? Subscribing to notifications could be a
>>> work-around but it’s not ideal.
>>> >
>>> > Good question. I can't really think of a way to do this...
>>> >
>>> >> Are we going to get more high quality bug reports using Github? This
>>> may not be answerable without trying it out, but making issues easier to
>>> create issues could cause an influx of questions and non-cordova related
>>> bugs. This could add on to the difficulties of triaging and migrating bugs
>>> across repos.
>>> >
>>> > To be fair, we already get painful triage-work via GitHub just by
>>> > opening up Pull Requests to the public. People will use those to post
>>> > questions or issues, because they are unaware that there are other
>>> > support and issue filing avenues (they will mask them as PRs merging a
>>> > release branch into master). At least those people now have a more
>>> > obvious place to file issues: the Issues section on GitHub. We already
>>> > have a lot of triage work on JIRA as it is. I doubt this will go down.
>>> > That said, I don't think that's necessarily bad. Will we have more
>>> > work? Probably. Will we be able to more easily identify issues, and
>>> > earlier, and generally be also more accessible to our community? I
>>> > would think yes. Double-edged sword. I say let's see how it goes.
>>> >
>>> >> If we migrate before triaging where will all the un-triaged issues end
>>> up?
>>> >
>>> > They would end up in GitHub, at which point we'd triage them within
>>> GitHub.
>>> >
>>> >> Also if we enable Github issues before phase 2 are we going to be using
>>> both Jira and Github Issues for a period of time?
>>> >
>>> > Yes.
>>> >
>>> > Different topic: Shaz, based on your INFRA ticket / phase breakdown,
>>> > the implication is that there will be leftover cordova repos in Apache
>>> > Git (cordova-medic, weinre, deprecated platforms / plugins). What do
>>> > we do with those? Separate discussion?
>>> >
>>> > On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson <cjp...@gmail.com> wrote:
>>> >> I have a few questions about moving issues to GitHub. I haven’t used
>>> Github
>>> >> issues much so these all may be easily solvable.
>>> >>
>>> >> * Since it looks like not all repositories will be migrated where should
>>> >> their issues go? What about issues for repositories that don’t yet
>>> exist or
>>> >> cross-cutting issues?
>>> >> * As a user, I’ll occasionally skim the recently opened bugs in Jira
>>> across
>>> >> the entire project to see if any may affect us. Is there going to be a
>>> way
>>> >> to do this with Github? Subscribing to notifications could be a
>>> work-around
>>> >> but it’s not ideal.
>>> >> * Are we going to get more high quality bug reports using Github? This
>>> may
>>> >> not be answerable without trying it out, but making issues easier to
>>> create
>>> >> issues could cause an influx of questions and non-cordova related bugs.
>>> >> This could add on to the difficulties of triaging and migrating bugs
>>> across
>>> >> repos.
>>> >> * If we migrate before triaging where will all the un-triaged issues end
>>> >> up? Also if we enable Github issues before phase 2 are we going to be
>>> using
>>> >> both Jira and Github Issues for a period of time?
>>> >>
>>> >> -Connor
>>> >>
>>> >>
>>> >> On August 2, 2017 at 7:08:18 PM, Jan Piotrowski (piotrow...@gmail.com)
>>> >> wrote:
>>> >>
>>> >> If people post their issue at the wrong repo (which of course can and
>>> >> will happen from time to time), there is a way to move them over with
>>> >> minimal loss of information:
>>> >>
>>> >> https://github.com/ionic-team/ionic/issues/12542
>>> >> https://github.com/ionic-team/ionic-cli/issues/2597
>>> >>
>>> >> This works for issues where several people replied already in the
>>> >> exact same way:
>>> >>
>>> >> https://github.com/ionic-team/ionic/issues/11898
>>> >> https://github.com/ionic-team/ionic-cli/issues/2386
>>> >>
>>> >> As the original poster of the issue and each reply is @-mentioned they
>>> >> are notified about the "new" issue and can continue participating.
>>> >> Replying users also can just include the @username in their new
>>> >> replies again to make sure people get notified.
>>> >>
>>> >> -J
>>> >>
>>> >>
>>> >>
>>> >> 2017-08-02 21:53 GMT+02:00 Filip Maj <maj....@gmail.com>:
>>> >>> I think the ease of use of GitHub issues overcomes potential problems
>>> >>> about cross-referencing issues. Worth noting on this topic that GitHub
>>> >>> already provides good support for referencing pull requests from
>>> >>> issues across repos / orgs.
>>> >>>
>>> >>> The benefit of having issues and PRs in one place, to me, is a benefit
>>> >>> too tasty to pass up.
>>> >>>
>>> >>> Darryl, do you have examples of issues that you think could be
>>> >>> problematic in a GitHub-based world?
>>> >>>
>>> >>> On Wed, Aug 2, 2017 at 12:43 PM, Darryl Pogue <dar...@dpogue.ca>
>>> wrote:
>>> >>>> My concern with GitHub issues is that we have a tonne of repos and
>>> >> issues
>>> >>>> can easily span across them, and we'd lose the one central place for
>>> >> issue
>>> >>>> tracking and triage. I worry that we'd be inundated with issues on the
>>> >>>> wrong repos, or without additional information, and triaging would
>>> >> become
>>> >>>> an insurmountable chore leading to a worse backlog than we already
>>> have
>>> >> in
>>> >>>> JIRA.
>>> >>>>
>>> >>>> On 2 August 2017 at 12:38, Shazron <shaz...@apache.org> wrote:
>>> >>>>
>>> >>>>> Phase 1 of our move to Github is complete, see:
>>> >>>>> https://issues.apache.org/jira/browse/INFRA-14347
>>> >>>>>
>>> >>>>> We need a migration plan for moving JIRA issues to Github Issues
>>> before
>>> >> we
>>> >>>>> enable Github Issues on those repos.
>>> >>>>>
>>> >>>>> Once we figure those out, we can proceed with Phase 2:
>>> >>>>> https://issues.apache.org/jira/browse/INFRA-14398
>>> >>>>>
>>> >>>>> I'll start it off by saying that ideally we:
>>> >>>>> 1. Triage issues
>>> >>>>> 2. Automate migration of existing open issues to Github issues
>>> >>>>> 3. "Close off" the JIRA issues
>>> >>>>>
>>> >>>>> The impact of this is, the original reporters will not get notified
>>> of
>>> >>>>> further updates to the issue except for a link to the new issue on
>>> >> Github
>>> >>>>> as a JIRA comment (since they will not be subscribed to the Github
>>> >> issue).
>>> >>>>>
>>> >>>>> We could also migrate every open issue first, then triage later in
>>> >> Github,
>>> >>>>> as well.
>>> >>>>>
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> >>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>> >>>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> >> For additional commands, e-mail: dev-h...@cordova.apache.org
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Reply via email to