cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [DISCUSS] Moving JIRA issues to Github
Date Thu, 17 Aug 2017 22:36:16 GMT
Filed: https://issues.apache.org/jira/browse/INFRA-14901

On Thu, Aug 17, 2017 at 3:28 PM, Shazron <shazron@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 <cjp822@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 (shazron@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.fil@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 <piotrowski@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 <jcesarmobile@gmail.com>:
>
> What about security issues?
>
> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <piotrowski@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.fil@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 <cjp822@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 (piotrowski@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.fil@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 <darryl@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 <shazron@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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message