Re: Disabling Closed -> Reopened transition for non-committers

[Nicholas Chammas]

Whoops, didn’t mean to send that out to the list. Apologies. Somehow, an
earlier draft of my email got sent out.

Nick


2017년 10월 5일 (목) 오전 9:20, Nicholas Chammas 님이
작성:

> The first sign that that conversation was going to go downhill was when
> the user [demanded](
> https://issues.apache.org/jira/browse/SPARK-21999?focusedCommentId=16166516=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16166516
> ):
>
> > Since we have ruled that out and given that [other conditions] could you
> have it tracked down and resolved ?
>
> Nick
>

>
> On Wed, Oct 4, 2017 at 10:06 PM Sean Owen  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
>>
>>

Re: Disabling Closed -> Reopened transition for non-committers

[Ryan Blue]

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  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  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  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 :
>>>
 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 
 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  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 

Re: Disabling Closed -> Reopened transition for non-committers

[lucas.g...@gmail.com]

I missed Steve's comments :(

That looks like a really healthy process, but also time consuming.

I guess that's what it takes to make a community?

Gary

Re: Disabling Closed -> Reopened transition for non-committers

[Sean Owen]

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  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  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 :
>>
>>> 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 
>>> 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  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 

Re: Disabling Closed -> Reopened transition for non-committers

[lucas.g...@gmail.com]

As a casual reader of the dev mailing group / Spark JIRA

This looks reasonable to me.  I read the JIRA in question and although I
didn't spend enough time to really dig into the issues presented I think
it's reasonable to close in this situation.

If the person with the grievance feels strongly it's really their onus to
send email to the dev group and find other ways to engage.



On 5 October 2017 at 04:44, Hyukjin Kwon  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 :
>
>> 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 
>> 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  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 
>>> 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  wrote:

> We have this problem occasionally, where a disgruntled user
> continually reopens an issue after it's closed.
>
> 

Re: Disabling Closed -> Reopened transition for non-committers

[Ryan Blue]

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  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 :
>
>> 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 
>> 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  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 
>>> 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  wrote:

Re: Disabling Closed -> Reopened transition for non-committers

[Hyukjin Kwon]

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 :

> 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 
> 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  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 
>> 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  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


>>>
>>

Re: Disabling Closed -> Reopened transition for non-committers

[Steve Loughran]

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 
> 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 
> 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 
> 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

Re: Disabling Closed -> Reopened transition for non-committers

[Sean Owen]

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 
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  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 
> 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  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
>>>
>>>
>>
>

Re: Disabling Closed -> Reopened transition for non-committers

[Sean Owen]

Yes this only pertains to JIRA.
Yes the committer role in JIRA isn't synced to the committer LDAP group but
we have admin rights to add people to roles so can easily add any new
committers that are missing.

On Thu, Oct 5, 2017, 05:50 Felix Cheung <felixcheun...@hotmail.com> wrote:

> To be sure, this is only for JIRA and not for github PR, right?
>
> If then +1 but I think the access control on JIRA does not necessarily
> match the committer list, and is manually maintained, last I hear.
>
> --
> *From:* Sean Owen <so...@cloudera.com>
> *Sent:* Wednesday, October 4, 2017 7:51:37 PM
> *To:* Dongjoon Hyun
> *Cc:* dev
> *Subject:* Re: Disabling Closed -> Reopened transition for non-committers
>
> 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
>>>
>>>
>>

Re: Disabling Closed -> Reopened transition for non-committers

[Felix Cheung]

To be sure, this is only for JIRA and not for github PR, right?

If then +1 but I think the access control on JIRA does not necessarily match 
the committer list, and is manually maintained, last I hear.


From: Sean Owen <so...@cloudera.com>
Sent: Wednesday, October 4, 2017 7:51:37 PM
To: Dongjoon Hyun
Cc: dev
Subject: Re: Disabling Closed -> Reopened transition for non-committers

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<mailto: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<mailto: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

Re: Disabling Closed -> Reopened transition for non-committers

[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.
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 
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  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
>>
>>
>

Re: Disabling Closed -> Reopened transition for non-committers

[Dongjoon Hyun]

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  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
>
>

Disabling Closed -> Reopened transition for non-committers

[Sean Owen]

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