> 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
