Some examples to illustrate my point. A couple of issues from the oldest
open issues
in the SQL component:
[SQL] spark-sql exits while encountered an error
https://issues.apache.org/jira/browse/SPARK-4572
This is an incomplete report that nobody can take action on. It can be
resolved
as
On Thu, May 21, 2015 at 9:06 PM, Santiago Mola sm...@stratio.com wrote:
Inactive - A feature or bug that has had no activity from users or
developers in a long time
Why is this needed? Every JIRA listing can be sorted by activity. That gets
the inactive ones out of your view quickly. I do not
2015-05-12 9:50 GMT+02:00 Patrick Wendell pwend...@gmail.com:
Inactive - A feature or bug that has had no activity from users or
developers in a long time
Why is this needed? Every JIRA listing can be sorted by activity. That gets
the inactive ones out of your view quickly. I do not see any
On Thu, May 21, 2015 at 10:03 PM, Santiago Mola sm...@stratio.com wrote:
Sure. That is why I was talking about the Inactive resolution specifically.
The
combination of Priority + other statuses are enough to solve these issues. A
minor/trivial issue that is incomplete is probably not going to
If there is no further feedback on this I will ask ASF Infra to add
the new fields Out of Scope and Inactive.
- Patrick
On Tue, May 12, 2015 at 9:02 AM, Nicholas Chammas
nicholas.cham...@gmail.com wrote:
I tend to find that any large project has a lot of walking dead JIRAs, and
pretending they
In Spark we sometimes close issues as something other than Fixed,
and this is an important part of maintaining our JIRA.
The current resolution types we use are the following:
Won't Fix - bug fix or (more often) feature we don't want to add
Invalid - issue is underspecified or not appropriate
I tend to find that any large project has a lot of walking dead JIRAs, and
pretending they are simply Open causes problems. Any state is better for
these, so I favor this.
Agreed.
1. Inactive: A way to clear out inactive/dead JIRA’s without
indicating a decision has been made one way or
I tend to find that any large project has a lot of walking dead JIRAs, and
pretending they are simply Open causes problems. Any state is better for
these, so I favor this.
The possible objection is that this will squash or hide useful issues, but
in practice we have the opposite problem. Resolved