That makes more sense. If this is something that committers can do to stop a single issue from being reopened, I'm more okay with that. But we need to make sure that we don't accidentally use it when closing issues or over-use it. I guess I'm +0 on it.
On Thu, Oct 5, 2017 at 9:04 AM, Sean Owen <so...@cloudera.com> wrote: > 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 >> > -- Ryan Blue Software Engineer Netflix
