For security, we already get requests sent to our private mailing list ( priv...@cordova.apache.org). We then create a private issue to track the problem and only make it public once we solve the problem and do a release.
Instead of a private jira instance, we could use a private github repo. Follow the same steps otherwise. On Thu, Aug 3, 2017 at 9:00 AM, Filip Maj <maj....@gmail.com> wrote: > 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 > >
