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 <rb...@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 <gurwls...@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 <so...@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 <ste...@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 <so...@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.h...@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 <so...@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 >
