Filed: https://issues.apache.org/jira/browse/INFRA-14901
On Thu, Aug 17, 2017 at 3:28 PM, Shazron <shaz...@gmail.com> wrote: > I'm afraid that will be something INFRA would need to do. As part of the > Gitbox project, the repo is moved from git-wip-us.a.o to gitbox.a.o > > So for example, this issue: > https://issues.apache.org/jira/browse/CB-4725 > > Has the old link: > https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=80a09b8 > > You would replace `git-wip-us` with `gitbox` and it should work: > https://gitbox.apache.org/repos/asf?p=cordova-android.git;h=80a09b8 > <https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=80a09b8> > > I suppose we could file a feature request with INFRA to try to map the old > repos to their gitbox equivalents. > > On Aug 17, 2017 at 3:05 PM, Connor Pearson <cjp...@gmail.com> wrote: > > > Thanks, Shazron. I think that clears up all my questions on issues. I have > a question about the code move though. > > I was looking into an older Jira item today and noticed that all the links > to cordova-android commits fail. Is it possible to make the original > repositories mirrors of the Github ones or leave them as a read-only > archive? > > > On August 12, 2017 at 2:42:42 AM, Shazron (shaz...@gmail.com) wrote: > > Clearing up some questions here. > > @dpogue > --- > True, we will have to rely on users filing issues in the right place. JIRA > however, does not make it easy to do that since they start with a blank > slate. When a user files an issue on a repo, they 95% know it applies to > that repo. > > The 5% of the time is people filing issues under a platform when it really > should be under a plugin or a tool. Like @janpiotrowski mentioned, we could > do a "manual" move (like how Ionic does it), but it can get tedious. I wish > Github had a way to move an issue. > > @connorpearson > --- > The move to Github is primarily for: > 1. Less friction for people to file issues > 2. Active/High traffic repo management > > Therefore the less active repos (effectively dead) we are not concerned > about since we don't plan on working on them anymore (new features, bug > fixes). This includes the deprecated components. All issues will be closed > for those since effectively we "Won't Fix". > > We will only migrate open issues for the repos that are to be migrated. > > cordova-plugins is in the migration plan: > https://github.com/cordova/cordova-discuss/blob/master/ > proposals/GithubMove.md > > As issues for repos that don't exist -- all issues should correspond to an > issue in the code, thus they should be tied to a repo, I can't foresee an > orphan issue -- my suggestion is to just file an issue to the repo you > think is "closest" in that case. > > There are however cases in JIRA where an issue is for "AllPlugins" or > "AllComponents". We would have to unroll those into tasks for each plugin > or component, create one for each. We lose JIRA's subtask feature however. > If we ever need the subtask functionality we can do a "Github Project" > (which can span a GH org) for the N tasks -- but unfortunately they are > standalone and cannot be part of another Project board. > > @filmaj > --- > Leftover repos we don't want any activity really since we don't plan on > working on them anymore, so no point in migrating. Deprecated component > issues will only exist in JIRA. > > @janpiotrowski > --- > Good idea to perhaps use status.cordova.io repo to perhaps house this > aggregate view of all the relevant Cordova repos, although @filmaj's idea > of using the Github Issues browser and targeted queries could work just as > well -- perhaps status.github.io can just host these constructed links > that > we want. > > @julio > --- > Unfortunately the security issues cannot be migrated until these can be > resolved: > 1. Can we get a private repo for security issues on Github? It might be > cost-prohibitive to upgrade since an org will have to pay for each user in > the org, per month (regardless of them using the private repo). Not sure if > Apache has some sort of deal with GH. > 2. A security reporter can't file a Private issue in Github, unlike in > JIRA. This is less of a problem since the PMC can file it, but see point 3 > below. > 3. Private Issue View Granularity. Right now if a security reporter > files a Private Issue in JIRA, they and the PMC can view and comment on the > issue, and have a real conversation. Github however doesn't provide > granularity on a per issue level. We don't want a security reporter to have > access to the other security issues they are not part of. Again, this might > not be a problem if we are the only ones having a discussion on it, but it > would be nice versus having a dual Github and email disjointed > conversation. > > > NEXT STEPS: > --- > I'll add some of these issues, and you should also continue this discussion > in: > https://github.com/cordova/cordova-discuss/pull/75 > > > > > > > On 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 > >
