Also, we are trying to formalize the proposal at https://github.com/cordova/cordova-discuss/pull/75
On Wed, Aug 9, 2017 at 10:20 AM, Steven Gill <stevengil...@gmail.com> wrote: > 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 >> >> >
