I was under the impression that JIRA was already locked down for everyone
but PMC members. But yesterday I received a comment on an old JIRA issue.
Under these circumstances, I see the benefits of bulk-closing all JIRA
issues.
Nevertheless, I would really like to
1. have a two way link
Auto-correction sorry!
Anyways, I also agree with *Shazron's* point of view on this and will also
> go with the consensus.
On Fri, Aug 24, 2018 at 12:06 PM Bryan Ellis wrote:
> Personally, I am also in favor for the issue bankruptcy.
>
>
> I use the LIFO method more when deciding tickets; so
Personally, I am also in favor for the issue bankruptcy.
I use the LIFO method more when deciding tickets; so looking at JIRA might
become less over time as GH issues grow.
I know that there can be relevant tickets, but someone will have to spend
time determining that.
-
Sort out
I think we have to take a look at whether we actually *will* look at
GH Issues *and* JIRA. This assumes that us, with limited time and
resources will actually do it.
I don't think I will, tbh. The issues are not lost, they are still in
JIRA for reference when the user wants to take it up again.
Realistically, if they created an issue more than 6 months ago and nobody
looked at it in that time, they wouldn't bother to recreate. So we would
lose ~1700 issues.
I agree with Raphael, if options are bulk close and ask for migration or
keep them open, I vote for keeping them open.
If somebody
I'm against migrating everything. I would just leave them in JIRA as is and
resolve them when resolved.
Regarding the "dangling" issues: If we re-file issues in GitHub, we would
have to make sure that the corresponding issue in JIRA is properly marked
as obsolete.
In other words, I as a
Back of the napkin calculation... if we took 5 mins (which is quite
conservative) to migrate one by one, 1,811*5 = 9,055 minutes (or ~19
days of 8 hours a day full time). That's about a month of work for one
person (not including weekends), but realistically it will be greater
than this of course,
Realistically doing it one by one will take a very long time, nor is
it necessary -- as a volunteer or if you were paid by your employer.
Some of these issues might be not relevant anymore. If it was
relevant, they can re-file in GH. I really don't want this to drag out
for another year.
In my
I wouldn't do a bulk close neither, I think we should migrate them one by
one to the respective github repo, even using same JIRA id so they still
get linked, and then manually close as duplicate of the new github one.
It's going to be a lot of work, but we don't need to do it right away, we
can
I thought JIRA was locked anyway. So only PMC Members can make changes.
If we just leave them as is, I can simply resolve an issue I fix in JIRA
and all is obvious.
If we ask people to reopen in GitHub, we will have a dangling seemingly
unresolved duplicate in JIRA,
so JIRA becomes less useful
Thanks Jan - I will hold off until we are ready of course.
Raphael - close as in there can not be any more comments added or
additions to the issue, not deletion. They will still exist and be
searchable. We definitely can add a label when we close them.
On Thu, Aug 23, 2018 at 5:01 PM Jan
Thanks for doing this!
I'm not sure about the bulk closing. Last time I checked, at least for our
tooling even very old issues were often still valid and provided some
valuable insight for me. I'd leave them.
If we want to close them, They should definitely get some label that makes
them easily
Just a note to make sure: Please do not proceed with this before issue
and PR templates are in place, labels are unified etc - meaning:
GitHub repos are ready.
(Working on this right now)
Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron :
>
> I've done this for our JIRA:
> - I've changed
I've done this for our JIRA:
- I've changed "Resolved" issues to "Closed" (about 8000+ of them)
- I've changed issues with "No Component" to the relevant component
What's left:
- We have 1881 Open, Reopened or In Progress issues
- 474 were created in the last year (52 weeks)
- thus
> 1. Should we just disable those then? One other way is to add in bold
> big letters about the deprecation in the New Issue template
We should probably "just" define our deprecation and archival policy
(see other active thread). Depending on that, we can create another
INFRA issue to get taken
We could whip something up using https://glitch.com for a start
On Wed, Aug 8, 2018 at 11:34 AM Shazron wrote:
>
> Thanks Jan!
>
> 1. Should we just disable those then? One other way is to add in bold
> big letters about the deprecation in the New Issue template
> 2. These links are super useful.
Thanks Jan!
1. Should we just disable those then? One other way is to add in bold
big letters about the deprecation in the New Issue template
2. These links are super useful. Perhaps they should be on the
website, what do you all think? Not sure if the scripting for the
second link is server side
Please open a new discussion re the archiving/deprecation topic - this
is a very different thing.
Sure, feel free to transfer the links to a Github Wiki or whatever -
as I wanted to generate the links automatically I had to use a
scripting language.
2018-08-07 17:07 GMT+02:00 Chris Brody :
> I
I would favor archiving the deprecated repos asap so we don't have to
deal with traffic on those anymore.
Thanks for making the nice GitHub filter and group repo links. I would
really favor using a wiki, which is supported by GitHub, for this kind
of thing for the sake of easy writing & editing.
You may have noticed the first issues coming in on some repositories.
1. In hindsight enabling issues for deprecated platforms, plugins etc
may not have been the smartest decision. We will have to find out how
to handle this - we should probably write down a "deprecation /
archivation policy"
That worked, the ticket was just resolved and issues are now enabled
for all repos (beside cordova-weinre which is archived):
https://github.com/apache/cordova-android/issues
https://github.com/apache/cordova-ios/issues
https://github.com/apache/cordova-plugin-inappbrowser/issues
...
On to b),
On Mon, Aug 6, 2018 at 6:48 AM Jan Piotrowski wrote:
>
> Created INFRA issue at https://issues.apache.org/jira/browse/INFRA-16876
+100
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands,
Created INFRA issue at https://issues.apache.org/jira/browse/INFRA-16876
2018-08-02 17:29 GMT+02:00 :
>>
>> For Cordova tooling I expect no one outside of the developers to
>>
> really know what happens where - but if I see it correctly we almost
>> don't have any tooling JIRA issues as well,
>
> For Cordova tooling I expect no one outside of the developers to
>
really know what happens where - but if I see it correctly we almost
> don't have any tooling JIRA issues as well, right?
>
There's plenty tooling related JIRA issues. And rightly so.
IMHO, joining all tooling packages in a
> - How do people know in which of the numerous Cordova repos to create
> their issues (especially bad for tooling)
As Julio already indicated this is a communication problem, that we
can solve by having a page at issues.cordova.io. Pages like
https://cordova.apache.org/contribute/ also have
> we have issues.cordova.io that right now it just redirects to jira, so
> maybe we should have a web page were we list all the repos instead?
+1
> >- How to manage meta-issues that concern more than one repo (Can we
+1
> >productively use whatever tools GitHub provides here, or will
we have issues.cordova.io that right now it just redirects to jira, so
maybe we should have a web page were we list all the repos instead?
2018-08-02 16:51 GMT+02:00 :
> There is much I don't like about JIRA and in general I prefer GitHub
> issues. However, there's issues that did came up during
There is much I don't like about JIRA and in general I prefer GitHub
issues. However, there's issues that did came up during previous
discussions of this topic, and that have no proper solution that I know of
- How do people know in which of the numerous Cordova repos to create
their issues
+1
On Thu, Aug 2, 2018 at 10:34 AM Jan Piotrowski wrote:
>
> Decision making for Apache projects is described here:
> https://community.apache.org/committers/decisionMaking.html
>
> So to make it official:
> I hereby declare that I will start implementing the stuff from my
> initial email if
Decision making for Apache projects is described here:
https://community.apache.org/committers/decisionMaking.html
So to make it official:
I hereby declare that I will start implementing the stuff from my
initial email if nobody objects in the next 72 hours (meaning: before
next Monday). After
What will it take to take care of a) Enable GitHub issues on all
repositories via INFRA ticket?
I think this is needed really badly. There are way too many cases of
questions and issues being raised in the wrong place, lost in diverse
discussion forums, or not even asked at all.
On Wed, Aug 1,
Another one:
f) Find and activate way for Github issue (and PR) updates to be
posted so Slack #issues
2018-07-31 18:14 GMT+02:00 Jan Piotrowski :
> The npm forum solves a very different problem for npm - they had too
> much noise in Github issues because of the project's popularity. Too
> much
The npm forum solves a very different problem for npm - they had too
much noise in Github issues because of the project's popularity. Too
much popularity is not one of Cordova's problems ;)
Many uses of cordova-discuss will be able to move to the individual
project repositories issues, maybe we
+1 (+100) for migrating away from JIRA issues
npm took a different approach that I am starting to really like: using
npm.community (Discourse) with GitHub login for issues and discussions
solves another major problem since I don't like mail list for
discussing issues and cordova-discuss has
34 matches
Mail list logo
