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