spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyukjin Kwon <gurwls...@gmail.com>
Subject Re: Disabling Closed -> Reopened transition for non-committers
Date Thu, 05 Oct 2017 11:44:37 GMT
It's, Closed -> Reopened (not, Resolved -> Reopened) and I think we mostly
leave JIRAs as Resolved.

I support this idea. I think don't think this is unfriendly as it sounds in
practice. This case should be quite occasional I guess.


2017-10-05 20:02 GMT+09:00 Sean Owen <sowen@cloudera.com>:

> Solving it socially is of course ideal. We do already likewise point
> everyone to http://spark.apache.org/contributing.html . I think this is
> about what to do in extreme cases. It's a minor point of workflow, but,
> seems like there's no particular need to let anyone reopen any issue.
>
> Speaking to the particular issue, maybe the error can be improved, but it
> already shows ClosureCleaner calling ensureSerializable and saying "task
> not serializable" and the object in question. That wasn't quite the issue
> though, but rather that it was a) an extended question about how batches
> are processed mixed with b) basic misapprehensions about Spark and c)
> unacceptable tone for an OSS community from start to finish. Closing it is
> the right resolution for several reasons, and I don't see that a better
> exception message would have done anything.
>
> On Thu, Oct 5, 2017 at 11:38 AM Steve Loughran <stevel@hortonworks.com>
> wrote:
>
>> 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"
>>
>> https://wiki.apache.org/hadoop/InvalidJiraIssues
>>
>> and a video to go into detail
>>
>> https://www.youtube.com/watch?v=NaJlRk5aTRQ
>>
>>
>> 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
>> org.apache.hadoop.net.NetUtils#wrapException , 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 <sowen@cloudera.com> wrote:
>>
>> 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. https://issues.
>> apache.org/jira/browse/INFRA-11857?jql=project%20%3D%
>> 20INFRA%20AND%20text%20~%20%22reopen%20JIRA%22
>>
>> 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 important.
>>
>> 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 <dongjoon.hyun@gmail.com>
>> wrote:
>>
>>> It can stop reopening, but new JIRA issues with duplicate content will
>>> be created intentionally instead.
>>>
>>> Is that policy (privileged reopening) used in other Apache communities
>>> for that purpose?
>>>
>>>
>>> On Wed, Oct 4, 2017 at 7:06 PM, Sean Owen <sowen@cloudera.com> wrote:
>>>
>>>> We have this problem occasionally, where a disgruntled user continually
>>>> reopens an issue after it's closed.
>>>>
>>>> https://issues.apache.org/jira/browse/SPARK-21999
>>>>
>>>> (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: https://issues.apache.org/
>>>> jira/browse/INFRA-15221
>>>>
>>>>
>>>
>>

Mime
View raw message