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:20:10 GMT
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