spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <so...@cloudera.com>
Subject Re: Disabling Closed -> Reopened transition for non-committers
Date Thu, 05 Oct 2017 16:04:06 GMT
Yeah to be clear I'm not suggesting that -- issues are just "Resolved" in
general which anyone can continue reopening. That's exactly because new
facts can come to light, a different opinion can arrive later, etc.

I'm trying to have some control over someone repeatedly reopening issues
every 15 minutes. It's a particular kind of abuse that's come up a few
times on this project. It still doesn't stop people from opening new JIRAs
or whatever.

Note anyone can still comment on closed issues.

I also suggested it because this behavior appears to be the default for ASF
projects. It wasn't clear why Spark was setup differently.

On Thu, Oct 5, 2017 at 5:00 PM Ryan Blue <rblue@netflix.com> wrote:

> While I have also felt this frustration and understand the motivation, I
> don't think it's a good idea to disallow people from reopening issues.
>
> Like Steve said, this is something that is better dealt with socially. If
> we did implement this, we're shutting out the polite people when *we* make
> mistakes and close issues, or are making it more difficult for the person
> to add what information was missing. Plus, we're making it harder for the
> reviewer that sees the follow-up issue and has none of the previous context.
>
> rb
>
> On Thu, Oct 5, 2017 at 4:44 AM, Hyukjin Kwon <gurwls223@gmail.com> wrote:
>
>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
>
> --
> Ryan Blue
> Software Engineer
> Netflix
>

Mime
View raw message