spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Disabling Closed -> Reopened transition for non-committers
Date Thu, 05 Oct 2017 10:38:05 GMT
It's a losing battle which you need to deal with socially rather than through the tooling...if
the user is unhappy then at best they don't use the code, don't contribute in future, at worse:
they keep filing the same JIRA. I'll add a comment

In hadoop we've ended up creating a wiki page added as a link when closing things as an invalid,
usually with a polite let down "sorry"

and a video to go into detail

There's something to consider though: how can error reporting be improved? Especially for
people new to a system?

Serialization errors are ubiquitous in spark when you call RDDs with unserializable data;
the first thing people learn when they start writing them is "this stack trace means I'm invoking
something which can't go over the wire". So: how to help people over the hump there? catch
& wrap with a pointer to some docs. For networking, feel free to use , where the links to wiki entries are lists of
"common causes of these networking issues" are a checklist for everyone; the real facts of
hostnames and ports are there for tracking things down.  The core Java io networking errors
are without meaningful information, so it's up to the layers above to fix.

On 5 Oct 2017, at 03:51, Sean Owen <<>>

Although I assume we could get an account suspended if it started opening spam issues, yes
we default to letting anyone open issues, and potentially abusing it. That much is the right
default and I don't see any policy tweak that stops that.

I see several INFRA tickets asking to *allow* the Closed -> Reopened transition, which
suggests it's not the default.

I'm accustomed to Closed being a final state that nobody can reopen as a matter of workflow
-- the idea being that anything else should be a new discussion if the current issue was deemed
formally done.

Spark pretty much leaves all issues in "Resolved" status which can still be reopened, and
I think that's right. Although I'd like to limit all reopening to committers, it isn't that

Being able to move a JIRA to Closed permanently seems useful, as it doesn't interfere with
any normal workflow, doesn't actually prevent a new issue from succeeding it in normal usage,
and gives another tool to limit a specific kind of abuse.

On Thu, Oct 5, 2017 at 3:28 AM Dongjoon Hyun <<>>
It can stop reopening, but new JIRA issues with duplicate content will be created intentionally

Is that policy (privileged reopening) used in other Apache communities for that purpose?

On Wed, Oct 4, 2017 at 7:06 PM, Sean Owen <<>>
We have this problem occasionally, where a disgruntled user continually reopens an issue after
it's closed.

(Feel free to comment on this one if anyone disagrees)

Regardless of that particular JIRA, I'd like to disable to Closed -> Reopened transition
for non-committers:

View raw message