You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@apache.org> on 2017/08/02 19:38:41 UTC
[DISCUSS] Moving JIRA issues to Github
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.
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Filip Maj <ma...@gmail.com>.
> 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?
Possibly. I think we will still have JIRA around w/ deprecated
components, maybe? I'm not sure. Shaz?
> 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?
To create new repos, we will have to go through Infra anyways.
Experimental code in cordova has gone into branches in the
cordova-labs repo in the past.
> Is there going to be a default repository to hold them before they're
> triaged and organized?
Oh I think I see what you mean now. As in, what do we do with JIRA
issues without an assigned component that does maps to one of the new
GH repos, what do we do with those? That's a good question. Perhaps
that points to us doing a big JIRA issue cleanup before we undergo a
migration. FWIW I did a couple weeks back already and am fairly
confident most relevant issues have an assigned component.
On Wed, Aug 2, 2017 at 6:51 PM, Connor Pearson <cj...@gmail.com> wrote:
>>> 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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Connor Pearson <cj...@gmail.com>.
>> 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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
>
>
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Shazron <sh...@gmail.com>.
Filed: https://issues.apache.org/jira/browse/INFRA-14901
On Thu, Aug 17, 2017 at 3:28 PM, Shazron <sh...@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 <cj...@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 <ma...@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 <pi...@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 <jc...@gmail.com>:
>
> What about security issues?
>
> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <pi...@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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
>
>
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Shazron <sh...@gmail.com>.
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 <cj...@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 <ma...@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 <pi...@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 <jc...@gmail.com>:
What about security issues?
El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <pi...@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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Connor Pearson <cj...@gmail.com>.
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 <ma...@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 <pi...@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 <jc...@gmail.com>:
What about security issues?
El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <pi...@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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Shazron <sh...@gmail.com>.
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 <ma...@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 <pi...@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 <jc...@gmail.com>:
What about security issues?
El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <pi...@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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Connor Pearson <cj...@gmail.com>.
I think the web interface is a good idea. It might help triage as well if
you're able to search and filter issues across the entire project. I think
it might need to have some mechanism for excluding or grouping migrated
issues too.
On Thu, Aug 3, 2017 at 5:55 AM, julio cesar sanchez <jc...@gmail.com>
wrote:
> What about security issues?
>
> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <pi...@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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
> >
> >
>
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Steven Gill <st...@gmail.com>.
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 <st...@gmail.com> wrote:
> For security, we already get requests sent to our private mailing list (
> private@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 <ma...@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 <pi...@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" <pi...@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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
>>
>>
>
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Steven Gill <st...@gmail.com>.
For security, we already get requests sent to our private mailing list (
private@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 <ma...@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 <pi...@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 <jc...@gmail.com>:
> >> What about security issues?
> >>
> >> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <pi...@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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
>
>
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Filip Maj <ma...@gmail.com>.
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 <pi...@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 <jc...@gmail.com>:
>> What about security issues?
>>
>> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <pi...@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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Jan Piotrowski <pi...@gmail.com>.
> 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 <jc...@gmail.com>:
> What about security issues?
>
> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <pi...@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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by julio cesar sanchez <jc...@gmail.com>.
What about security issues?
El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <pi...@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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
>
>
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Jan Piotrowski <pi...@gmail.com>.
>> 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 <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Filip Maj <ma...@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 <cj...@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 <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Connor Pearson <cj...@gmail.com>.
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 <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Jan Piotrowski <pi...@gmail.com>.
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 <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Filip Maj <ma...@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 <da...@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 <sh...@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
Re: [DISCUSS] Moving JIRA issues to Github
Posted by Darryl Pogue <da...@dpogue.ca>.
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 <sh...@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.
>