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
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 a
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
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
mista
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
yep, looking now.
On Wed, Oct 4, 2017 at 10:04 PM, Felix Cheung
wrote:
> Hmm, sounds like some sort of corruption of the maven directory on the
> Jenkins box...
>
>
> --
> *From:* Liwei Lin
> *Sent:* Wednesday, October 4, 2017 6:52:54 PM
> *To:* Spark dev list
> *Sub
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 mi
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
yep, it was a corrupted jar on amp-jenkins-worker-01. i grabbed a new one
from maven.org and kicked off a fresh build.
On Thu, Oct 5, 2017 at 9:03 AM, shane knapp wrote:
> yep, looking now.
>
> On Wed, Oct 4, 2017 at 10:04 PM, Felix Cheung
> wrote:
>
>> Hmm, sounds like some sort of corruption
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 wr
Thanks Shane!
From: shane knapp
Sent: Thursday, October 5, 2017 9:14:54 AM
To: Felix Cheung
Cc: Liwei Lin; Spark dev list
Subject: Re: Nightly builds for master branch failed
yep, it was a corrupted jar on amp-jenkins-worker-01. i grabbed a new one from
maven.o
not a problem. :)
On Thu, Oct 5, 2017 at 9:26 AM, Felix Cheung
wrote:
> Thanks Shane!
>
> --
> *From:* shane knapp
> *Sent:* Thursday, October 5, 2017 9:14:54 AM
> *To:* Felix Cheung
> *Cc:* Liwei Lin; Spark dev list
> *Subject:* Re: Nightly builds for master branch
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/ji
...and we're green:
https://amplab.cs.berkeley.edu/jenkins/job/spark-master-maven-snapshots/2025/
On Thu, Oct 5, 2017 at 9:46 AM, shane knapp wrote:
> not a problem. :)
>
> On Thu, Oct 5, 2017 at 9:26 AM, Felix Cheung
> wrote:
>
>> Thanks Shane!
>>
>> --
>> *From:*
Thanks Shane.
2017-10-06 2:07 GMT+09:00 shane knapp :
> ...and we're green: https://amplab.cs.berkeley.edu/jenkins/job/
> spark-master-maven-snapshots/2025/
>
> On Thu, Oct 5, 2017 at 9:46 AM, shane knapp wrote:
>
>> not a problem. :)
>>
>> On Thu, Oct 5, 2017 at 9:26 AM, Felix Cheung
>> wrot
+1 (non-binding)
On Wed, Oct 4, 2017 at 11:08 PM Holden Karau wrote:
> Awesome, thanks for digging into the packaging on the R side in more
> detail. I'll look into how to update the keys file as well.
>
> On Wed, Oct 4, 2017 at 10:46 PM Felix Cheung
> wrote:
>
>> +1
>>
>> Tested SparkR packag
+1
On Mon, Oct 2, 2017 at 11:24 PM, Holden Karau wrote:
> Please vote on releasing the following candidate as Apache Spark version 2
> .1.2. The vote is open until Saturday October 7th at 9:00 PST and passes
> if a majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as
+1 too.
On 6 Oct 2017 10:49 am, "Reynold Xin" wrote:
+1
On Mon, Oct 2, 2017 at 11:24 PM, Holden Karau wrote:
> Please vote on releasing the following candidate as Apache Spark version 2
> .1.2. The vote is open until Saturday October 7th at 9:00 PST and passes
> if a majority of at least 3 +
+1 (non binding ) tested on Ubuntu ,all test case are passed.
Regards,
Vaquar khan
On Thu, Oct 5, 2017 at 10:46 PM, Hyukjin Kwon wrote:
> +1 too.
>
>
> On 6 Oct 2017 10:49 am, "Reynold Xin" wrote:
>
> +1
>
>
> On Mon, Oct 2, 2017 at 11:24 PM, Holden Karau
> wrote:
>
>> Please vote on releasi
19 matches
Mail list logo
