cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [DISCUSS] Moving JIRA issues to Github
Date Thu, 17 Aug 2017 22:28:01 GMT
 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 <cjp822@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 <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