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 > >
