Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
MIME-Version: 1.0
In-Reply-To: <CACWNLiQyovH+4FYaLAM8A346RQEwh6DjY-Ntfzay_j3JX2EbyQ@mail.gmail.com>
References: <CAE6O_-ZDAJzmg05TTLFPw+qVf4ZY4Ww+CBS7cWudjwLASZOYvA@mail.gmail.com>
 <CA+z8NA9+JPQchr6fWpQaQzjAd-ac0vBQG0itb98JXx04QL9-5w@mail.gmail.com>
 <CABqhctFSFY=z3Z69wYoUxRxOOufU_R-yzbqZaAtb_Rpd3gi0Tg@mail.gmail.com>
 <CACWNLiQsCgoB6=UyD3Mt4jSg5aJ6nrrhFL6T9_uhiPVkoOxFJQ@mail.gmail.com>
 <CAE82UFau7pyP5TqT61nBA6Q0JL6LQ5sdb3yciNJKovpv94a4WQ@mail.gmail.com>
 <CABqhctH3uFE7nF_pG8FfnLCTh2oOn5eQQteCbz5RYE5M2-+82w@mail.gmail.com>
 <CACWNLiRuhmzLqinUKBu3MNGfXi_LfL5RhdjkF5OCx_OL2hajPA@mail.gmail.com>
 <CAG5ZNwU5D3MmORU726teFMqwVNX7h8ASwaWXmgB+v3j71xvusA@mail.gmail.com> <CACWNLiQyovH+4FYaLAM8A346RQEwh6DjY-Ntfzay_j3JX2EbyQ@mail.gmail.com>
From: Filip Maj <maj.fil@gmail.com>
Date: Thu, 3 Aug 2017 09:00:31 -0700
Message-ID: <CABqhctEe5Tnrjk=upTaMXzyoT9jpkraXSO5eAi2cWEqreee4ew@mail.gmail.com>
Subject: Re: [DISCUSS] Moving JIRA issues to Github
To: dev@cordova.apache.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 03 Aug 2017 16:01:04 -0000

Did a little searching, and GitHub has a global issue search you can
use: https://github.com/issues

Combine that with a custom search query, essentially a giant chain of
(repo:apache/cordova-browser or repo:apache/cordova-android) etc., and
I think you could get what you want.

On Thu, Aug 3, 2017 at 4:30 AM, Jan Piotrowski <piotrowski@gmail.com> wrote=
:
>> What about security issues?
>> Right now on jira we have private security issues not visible for the re=
gular people and as far as I know, we can't do that on GitHub
>
> Initial idea: Have an email address where people can send messages to,
> the recipient then creates an issue on a private Github repo for
> further talking about it.
> You could probably also create a public form that does the same job of
> the email address and person creating the ticket automatically if too
> much effort and needed too often.
> (But maybe there is a better solution, one could investigate how other
> Github based projects do that)
>
> -J
>
> 2017-08-03 11:55 GMT+02:00 julio cesar sanchez <jcesarmobile@gmail.com>:
>> What about security issues?
>>
>> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <piotrowski@gmail.com> escri=
bi=C3=B3:
>>
>>> >> As a user, I=E2=80=99ll occasionally skim the recently opened bugs i=
n Jira
>>> across the entire project to see if any may affect us. Is there going t=
o be
>>> a way to do this with Github? Subscribing to notifications could be a
>>> work-around but it=E2=80=99s not ideal.
>>> >
>>> > Good question. I can't really think of a way to do this...
>>>
>>> Github doesn't offer this out of the box (besides watching all repos
>>> yourself, which comes with its own challenges). But Github has an API,
>>> I am pretty sure someone already wrote something that combines issues
>>> of several repos into one interface to look at, then links to the
>>> individual issues (If not, it wouldn't be too much work to create
>>> something like that) (Could become the new issues.cordova.io maybe?).
>>> Would this fulfill your use case?
>>>
>>> -J
>>>
>>> 2017-08-03 3:13 GMT+02:00 Filip Maj <maj.fil@gmail.com>:
>>> >> Since it looks like not all repositories will be migrated where shou=
ld
>>> their issues go?
>>> >
>>> > All repositories will be migrated.
>>> >
>>> >> What about issues for repositories that don=E2=80=99t 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=E2=80=99ll occasionally skim the recently opened bugs i=
n Jira
>>> across the entire project to see if any may affect us. Is there going t=
o be
>>> a way to do this with Github? Subscribing to notifications could be a
>>> work-around but it=E2=80=99s 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 t=
o
>>> create issues could cause an influx of questions and non-cordova relate=
d
>>> bugs. This could add on to the difficulties of triaging and migrating b=
ugs
>>> 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 alread=
y
>>> > 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 e=
nd
>>> 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 us=
ing
>>> 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 Apach=
e
>>> > Git (cordova-medic, weinre, deprecated platforms / plugins). What do
>>> > we do with those? Separate discussion?
>>> >
>>> > On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson <cjp822@gmail.com> wro=
te:
>>> >> I have a few questions about moving issues to GitHub. I haven=E2=80=
=99t used
>>> Github
>>> >> issues much so these all may be easily solvable.
>>> >>
>>> >> * Since it looks like not all repositories will be migrated where sh=
ould
>>> >> their issues go? What about issues for repositories that don=E2=80=
=99t yet
>>> exist or
>>> >> cross-cutting issues?
>>> >> * As a user, I=E2=80=99ll 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=E2=80=99s not ideal.
>>> >> * Are we going to get more high quality bug reports using Github? Th=
is
>>> 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 bu=
gs.
>>> >> 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 b=
e
>>> 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.co=
m)
>>> >> wrote:
>>> >>
>>> >> If people post their issue at the wrong repo (which of course can an=
d
>>> >> will happen from time to time), there is a way to move them over wit=
h
>>> >> 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 th=
ey
>>> >> are notified about the "new" issue and can continue participating.
>>> >> Replying users also can just include the @username in their new
>>> >> replies again to make sure people get notified.
>>> >>
>>> >> -J
>>> >>
>>> >>
>>> >>
>>> >> 2017-08-02 21:53 GMT+02:00 Filip Maj <maj.fil@gmail.com>:
>>> >>> I think the ease of use of GitHub issues overcomes potential proble=
ms
>>> >>> about cross-referencing issues. Worth noting on this topic that Git=
Hub
>>> >>> 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 bene=
fit
>>> >>> too tasty to pass up.
>>> >>>
>>> >>> Darryl, do you have examples of issues that you think could be
>>> >>> problematic in a GitHub-based world?
>>> >>>
>>> >>> On Wed, Aug 2, 2017 at 12:43 PM, Darryl Pogue <darryl@dpogue.ca>
>>> wrote:
>>> >>>> My concern with GitHub issues is that we have a tonne of repos and
>>> >> issues
>>> >>>> can easily span across them, and we'd lose the one central place f=
or
>>> >> issue
>>> >>>> tracking and triage. I worry that we'd be inundated with issues on=
 the
>>> >>>> wrong repos, or without additional information, and triaging would
>>> >> become
>>> >>>> an insurmountable chore leading to a worse backlog than we already
>>> have
>>> >> in
>>> >>>> JIRA.
>>> >>>>
>>> >>>> On 2 August 2017 at 12:38, Shazron <shazron@apache.org> wrote:
>>> >>>>
>>> >>>>> Phase 1 of our move to Github is complete, see:
>>> >>>>> https://issues.apache.org/jira/browse/INFRA-14347
>>> >>>>>
>>> >>>>> We need a migration plan for moving JIRA issues to Github Issues
>>> before
>>> >> we
>>> >>>>> enable Github Issues on those repos.
>>> >>>>>
>>> >>>>> Once we figure those out, we can proceed with Phase 2:
>>> >>>>> https://issues.apache.org/jira/browse/INFRA-14398
>>> >>>>>
>>> >>>>> I'll start it off by saying that ideally we:
>>> >>>>> 1. Triage issues
>>> >>>>> 2. Automate migration of existing open issues to Github issues
>>> >>>>> 3. "Close off" the JIRA issues
>>> >>>>>
>>> >>>>> The impact of this is, the original reporters will not get notifi=
ed
>>> of
>>> >>>>> further updates to the issue except for a link to the new issue o=
n
>>> >> Github
>>> >>>>> as a JIRA comment (since they will not be subscribed to the Githu=
b
>>> >> issue).
>>> >>>>>
>>> >>>>> We could also migrate every open issue first, then triage later i=
n
>>> >> 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