cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: [DISCUSS] Moving JIRA issues to Github
Date Wed, 09 Aug 2017 17:46:12 GMT
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 <stevengill97@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 <maj.fil@gmail.com> wrote:
>
>> Did a little searching, and GitHub has a global issue search you can
>> use: https://github.com/issues
>>
>> Combine that with a custom search query, essentially a giant chain of
>> (repo:apache/cordova-browser or repo:apache/cordova-android) etc., and
>> I think you could get what you want.
>>
>> On Thu, Aug 3, 2017 at 4:30 AM, Jan Piotrowski <piotrowski@gmail.com>
>> wrote:
>> >> What about security issues?
>> >> Right now on jira we have private security issues not visible for the
>> regular people and as far as I know, we can't do that on GitHub
>> >
>> > Initial idea: Have an email address where people can send messages to,
>> > the recipient then creates an issue on a private Github repo for
>> > further talking about it.
>> > You could probably also create a public form that does the same job of
>> > the email address and person creating the ticket automatically if too
>> > much effort and needed too often.
>> > (But maybe there is a better solution, one could investigate how other
>> > Github based projects do that)
>> >
>> > -J
>> >
>> > 2017-08-03 11:55 GMT+02:00 julio cesar sanchez <jcesarmobile@gmail.com
>> >:
>> >> What about security issues?
>> >>
>> >> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <piotrowski@gmail.com>
>> escribió:
>> >>
>> >>> >> As a user, I’ll occasionally skim the recently opened bugs
in Jira
>> >>> across the entire project to see if any may affect us. Is there going
>> to be
>> >>> a way to do this with Github? Subscribing to notifications could be
a
>> >>> work-around but it’s not ideal.
>> >>> >
>> >>> > Good question. I can't really think of a way to do this...
>> >>>
>> >>> Github doesn't offer this out of the box (besides watching all repos
>> >>> yourself, which comes with its own challenges). But Github has an API,
>> >>> I am pretty sure someone already wrote something that combines issues
>> >>> of several repos into one interface to look at, then links to the
>> >>> individual issues (If not, it wouldn't be too much work to create
>> >>> something like that) (Could become the new issues.cordova.io maybe?).
>> >>> Would this fulfill your use case?
>> >>>
>> >>> -J
>> >>>
>> >>> 2017-08-03 3:13 GMT+02:00 Filip Maj <maj.fil@gmail.com>:
>> >>> >> Since it looks like not all repositories will be migrated where
>> should
>> >>> their issues go?
>> >>> >
>> >>> > All repositories will be migrated.
>> >>> >
>> >>> >> What about issues for repositories that don’t yet exist
>> >>> >
>> >>> > Can you give me an example?
>> >>> >
>> >>> >> or cross-cutting issues?
>> >>> >
>> >>> > I think if you absolutely need issues related to multiple repos,
you
>> >>> > can always create multiple issues in all relevant repos and
>> >>> > cross-reference them.
>> >>> >
>> >>> >> As a user, I’ll occasionally skim the recently opened bugs
in Jira
>> >>> across the entire project to see if any may affect us. Is there going
>> to be
>> >>> a way to do this with Github? Subscribing to notifications could be
a
>> >>> work-around but it’s not ideal.
>> >>> >
>> >>> > Good question. I can't really think of a way to do this...
>> >>> >
>> >>> >> Are we going to get more high quality bug reports using Github?
>> This
>> >>> may not be answerable without trying it out, but making issues easier
>> to
>> >>> create issues could cause an influx of questions and non-cordova
>> related
>> >>> bugs. This could add on to the difficulties of triaging and migrating
>> bugs
>> >>> across repos.
>> >>> >
>> >>> > To be fair, we already get painful triage-work via GitHub just
by
>> >>> > opening up Pull Requests to the public. People will use those to
>> post
>> >>> > questions or issues, because they are unaware that there are other
>> >>> > support and issue filing avenues (they will mask them as PRs
>> merging a
>> >>> > release branch into master). At least those people now have a more
>> >>> > obvious place to file issues: the Issues section on GitHub. We
>> already
>> >>> > have a lot of triage work on JIRA as it is. I doubt this will go
>> down.
>> >>> > That said, I don't think that's necessarily bad. Will we have more
>> >>> > work? Probably. Will we be able to more easily identify issues,
and
>> >>> > earlier, and generally be also more accessible to our community?
I
>> >>> > would think yes. Double-edged sword. I say let's see how it goes.
>> >>> >
>> >>> >> If we migrate before triaging where will all the un-triaged
issues
>> end
>> >>> up?
>> >>> >
>> >>> > They would end up in GitHub, at which point we'd triage them within
>> >>> GitHub.
>> >>> >
>> >>> >> Also if we enable Github issues before phase 2 are we going
to be
>> using
>> >>> both Jira and Github Issues for a period of time?
>> >>> >
>> >>> > Yes.
>> >>> >
>> >>> > Different topic: Shaz, based on your INFRA ticket / phase breakdown,
>> >>> > the implication is that there will be leftover cordova repos in
>> Apache
>> >>> > Git (cordova-medic, weinre, deprecated platforms / plugins). What
do
>> >>> > we do with those? Separate discussion?
>> >>> >
>> >>> > On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson <cjp822@gmail.com>
>> wrote:
>> >>> >> I have a few questions about moving issues to GitHub. I haven’t
>> used
>> >>> Github
>> >>> >> issues much so these all may be easily solvable.
>> >>> >>
>> >>> >> * Since it looks like not all repositories will be migrated
where
>> should
>> >>> >> their issues go? What about issues for repositories that don’t
yet
>> >>> exist or
>> >>> >> cross-cutting issues?
>> >>> >> * As a user, I’ll occasionally skim the recently opened bugs
in
>> Jira
>> >>> across
>> >>> >> the entire project to see if any may affect us. Is there going
to
>> be a
>> >>> way
>> >>> >> to do this with Github? Subscribing to notifications could
be a
>> >>> work-around
>> >>> >> but it’s not ideal.
>> >>> >> * Are we going to get more high quality bug reports using Github?
>> This
>> >>> may
>> >>> >> not be answerable without trying it out, but making issues
easier
>> to
>> >>> create
>> >>> >> issues could cause an influx of questions and non-cordova related
>> bugs.
>> >>> >> This could add on to the difficulties of triaging and migrating
>> bugs
>> >>> across
>> >>> >> repos.
>> >>> >> * If we migrate before triaging where will all the un-triaged
>> issues end
>> >>> >> up? Also if we enable Github issues before phase 2 are we going
to
>> be
>> >>> using
>> >>> >> both Jira and Github Issues for a period of time?
>> >>> >>
>> >>> >> -Connor
>> >>> >>
>> >>> >>
>> >>> >> On August 2, 2017 at 7:08:18 PM, Jan Piotrowski (
>> piotrowski@gmail.com)
>> >>> >> wrote:
>> >>> >>
>> >>> >> If people post their issue at the wrong repo (which of course
can
>> and
>> >>> >> will happen from time to time), there is a way to move them
over
>> with
>> >>> >> minimal loss of information:
>> >>> >>
>> >>> >> https://github.com/ionic-team/ionic/issues/12542
>> >>> >> https://github.com/ionic-team/ionic-cli/issues/2597
>> >>> >>
>> >>> >> This works for issues where several people replied already
in the
>> >>> >> exact same way:
>> >>> >>
>> >>> >> https://github.com/ionic-team/ionic/issues/11898
>> >>> >> https://github.com/ionic-team/ionic-cli/issues/2386
>> >>> >>
>> >>> >> As the original poster of the issue and each reply is @-mentioned
>> they
>> >>> >> are notified about the "new" issue and can continue participating.
>> >>> >> Replying users also can just include the @username in their
new
>> >>> >> replies again to make sure people get notified.
>> >>> >>
>> >>> >> -J
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> 2017-08-02 21:53 GMT+02:00 Filip Maj <maj.fil@gmail.com>:
>> >>> >>> I think the ease of use of GitHub issues overcomes potential
>> problems
>> >>> >>> about cross-referencing issues. Worth noting on this topic
that
>> GitHub
>> >>> >>> already provides good support for referencing pull requests
from
>> >>> >>> issues across repos / orgs.
>> >>> >>>
>> >>> >>> The benefit of having issues and PRs in one place, to me,
is a
>> benefit
>> >>> >>> too tasty to pass up.
>> >>> >>>
>> >>> >>> Darryl, do you have examples of issues that you think could
be
>> >>> >>> problematic in a GitHub-based world?
>> >>> >>>
>> >>> >>> On Wed, Aug 2, 2017 at 12:43 PM, Darryl Pogue <darryl@dpogue.ca>
>> >>> wrote:
>> >>> >>>> My concern with GitHub issues is that we have a tonne
of repos
>> and
>> >>> >> issues
>> >>> >>>> can easily span across them, and we'd lose the one
central place
>> for
>> >>> >> issue
>> >>> >>>> tracking and triage. I worry that we'd be inundated
with issues
>> on the
>> >>> >>>> wrong repos, or without additional information, and
triaging
>> would
>> >>> >> become
>> >>> >>>> an insurmountable chore leading to a worse backlog
than we
>> already
>> >>> have
>> >>> >> in
>> >>> >>>> JIRA.
>> >>> >>>>
>> >>> >>>> On 2 August 2017 at 12:38, Shazron <shazron@apache.org>
wrote:
>> >>> >>>>
>> >>> >>>>> Phase 1 of our move to Github is complete, see:
>> >>> >>>>> https://issues.apache.org/jira/browse/INFRA-14347
>> >>> >>>>>
>> >>> >>>>> We need a migration plan for moving JIRA issues
to Github Issues
>> >>> before
>> >>> >> we
>> >>> >>>>> enable Github Issues on those repos.
>> >>> >>>>>
>> >>> >>>>> Once we figure those out, we can proceed with Phase
2:
>> >>> >>>>> https://issues.apache.org/jira/browse/INFRA-14398
>> >>> >>>>>
>> >>> >>>>> I'll start it off by saying that ideally we:
>> >>> >>>>> 1. Triage issues
>> >>> >>>>> 2. Automate migration of existing open issues to
Github issues
>> >>> >>>>> 3. "Close off" the JIRA issues
>> >>> >>>>>
>> >>> >>>>> The impact of this is, the original reporters will
not get
>> notified
>> >>> of
>> >>> >>>>> further updates to the issue except for a link
to the new issue
>> on
>> >>> >> Github
>> >>> >>>>> as a JIRA comment (since they will not be subscribed
to the
>> Github
>> >>> >> issue).
>> >>> >>>>>
>> >>> >>>>> We could also migrate every open issue first, then
triage later
>> in
>> >>> >> Github,
>> >>> >>>>> as well.
>> >>> >>>>>
>> >>> >>>
>> >>> >>> ------------------------------------------------------------
>> ---------
>> >>> >>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >>> >>> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>> >>>
>> >>> >>
>> >>> >> ------------------------------------------------------------
>> ---------
>> >>> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >>> >> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>> >
>> >>> > ------------------------------------------------------------
>> ---------
>> >>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >>> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>>
>> >>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
>

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