cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Connor Pearson <cjp...@gmail.com>
Subject Re: [DISCUSS] Moving JIRA issues to Github
Date Thu, 03 Aug 2017 01:51:21 GMT
>> Since it looks like not all repositories will be migrated where should
their issues go?
> All repositories will be migrated.

The one I was thinking of was cordova-plugins. Do we want some way to track
issues for inactive platforms too or should those be considered permanently
closed?

>> What about issues for repositories that don’t yet exist
> Can you give me an example?

For example a new platform or core plugin is created. I'd assume we could
create an empty repository, but I'm not sure what the overhead of
requesting a new repo is. Experimental plugins or research might fall into
this category as well. I guess the more general question is are there any
Jira tasks we use that aren't tied to a repo and if so where should track
them in Github?

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

Is there going to be a default repository to hold them before they're
triaged and organized?

On a slightly different note, I'm looking forward to the new PR process. It
always felt a little strange in the past.



On Wed, Aug 2, 2017 at 9:13 PM, Filip Maj <maj.fil@gmail.com> wrote:

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

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