Any way for users to help "stuck" JIRAs with pull requests for Spark 2.3 / future releases?

Hi all, I was wondering with the approach of Spark 2.3 if there's any way us "regular" users can help advance any of JIRAs that could have made it into Spark 2.3 but are likely to miss now as the pull requests are awaiting detailed review. For example: https://issues.apache.

Re: Suggestion in README.md for guiding pull requests/JIRAs (probably about linking CONTRIBUTING.md or wiki)

tter writing skills better than > me tries to fix this. > > I don't want to let reviewers make an effort to correct the grammar. > > > On 10 Oct 2016 1:34 a.m., "Sean Owen" wrote: > >> Yes, it's really CONTRIBUTING.md that's more releva

Re: Suggestion in README.md for guiding pull requests/JIRAs (probably about linking CONTRIBUTING.md or wiki)

as a better writing skills better than >> me tries to fix this. >> >> I don't want to let reviewers make an effort to correct the grammar. >> >> >> On 10 Oct 2016 1:34 a.m., "Sean Owen" wrote: >> >>> Yes, it's really CONTRIBUTING

Re: Suggestion in README.md for guiding pull requests/JIRAs (probably about linking CONTRIBUTING.md or wiki)

TRIBUTING.md that's more relevant, because github displays a link to it when opening pull requests. https://github.com/apache/spark/blob/master/CONTRIBUTING.md There is also the pull request template: https://github.com/apache/spark/blob/master/.github/PULL_REQUEST_TEMPLATE I wouldn'

Re: Suggestion in README.md for guiding pull requests/JIRAs (probably about linking CONTRIBUTING.md or wiki)

4 a.m., "Sean Owen" wrote: > Yes, it's really CONTRIBUTING.md that's more relevant, because github > displays a link to it when opening pull requests. https://github.com/a > pache/spark/blob/master/CONTRIBUTING.md There is also the pull request > template: https://githu

Re: Suggestion in README.md for guiding pull requests/JIRAs (probably about linking CONTRIBUTING.md or wiki)

Yes, it's really CONTRIBUTING.md that's more relevant, because github displays a link to it when opening pull requests. https://github.com/apache/spark/blob/master/CONTRIBUTING.md There is also the pull request template: https://github.com/apache/spark/blob/master/.github/PULL_REQUEST_T

Suggestion in README.md for guiding pull requests/JIRAs (probably about linking CONTRIBUTING.md or wiki)

Hi all, I just noticed the README.md (https://github.com/apache/spark) does not describe the steps or links to follow for creating a PR or JIRA directly. I know probably it is sensible to search google about the contribution guides first before trying to make a PR/JIRA but I think it seems not en

Re: auto closing pull requests that have been inactive > 30 days?

gt;>>> >>>>> >>>>> On Tue, Apr 19, 2016 at 4:52 AM, Sean Busbey >>>>> wrote: >>>>> >>>>>> Having a PR closed, especially if due to committers not having hte >>>>>> bandwidth to check on things, w

Re: auto closing pull requests that have been inactive > 30 days?

tions, which already do these things; it'll make it harder for bad contributions to distract from them. And I think the effect of a change like this is, in the main, to push back mostly on less good contributions. On Mon, Apr 18, 2016 at 8:02 PM, Reynold Xin wrote: > We have hit a new high

Re: auto closing pull requests that have been inactive > 30 days?

Thanks a lot for commenting. We are getting great feedback on this thread. The take-aways are: 1. In general people prefer having explicit reasons why pull requests should be closed. We should push committers to leave messages that are more explicit about why certain PR should be closed or not. I

Re: auto closing pull requests that have been inactive > 30 days?

>>>>> >>>>> Just my two cents. >>>>> >>>>> Thanks >>>>> Jerry >>>>> >>>>> >>>>> On Tue, Apr 19, 2016 at 4:52 AM, Sean Busbey >>>>> wrote: >>>>&

Re: auto closing pull requests that have been inactive > 30 days?

>>>> says "feel free to reopen for so-and-so reason", new folks who lack >>>>> confidence are going to see reopening as "pestering" and busy folks >>>>> are going to see it as a clear indication that their work is not even >>>>&

Re: auto closing pull requests that have been inactive > 30 days?

ose inexperienced with opensource. Even if the message >>>>> says "feel free to reopen for so-and-so reason", new folks who lack >>>>> confidence are going to see reopening as "pestering" and busy folks >>>>> are going to see it a

Re: auto closing pull requests that have been inactive > 30 days?

ton >>>> press. >>>> >>>> How about we start by keeping a report of "at-risk" PRs that have been >>>> stale for 30 days to make it easier for committers to look at the prs >>>> that have been long inactive? >>>> >&

Re: auto closing pull requests that have been inactive > 30 days?

t; press. >>> >>> How about we start by keeping a report of "at-risk" PRs that have been >>> stale for 30 days to make it easier for committers to look at the prs >>> that have been long inactive? >>> >>> >>> On Mon, Apr 18

Re: auto closing pull requests that have been inactive > 30 days?

the prs >> that have been long inactive? >> >> On Mon, Apr 18, 2016 at 2:52 PM, Reynold Xin wrote: >> > The cost of "reopen" is close to zero, because it is just clicking a >> button. >> > I think you were referring to the cost of closing the pull req

Re: auto closing pull requests that have been inactive > 30 days?

hink you were referring to the cost of closing the pull request, and > you > > are assuming people look at the pull requests that have been inactive > for a > > long time. That seems equally likely (or unlikely) as committers looking > at > > the recently closed pull reques

Re: auto closing pull requests that have been inactive > 30 days?

button. > I think you were referring to the cost of closing the pull request, and you > are assuming people look at the pull requests that have been inactive for a > long time. That seems equally likely (or unlikely) as committers looking at > the recently closed pull requests. > >

Re: auto closing pull requests that have been inactive > 30 days?

The cost of "reopen" is close to zero, because it is just clicking a button. I think you were referring to the cost of closing the pull request, and you are assuming people look at the pull requests that have been inactive for a long time. That seems equally likely (or unlikely) as

Re: auto closing pull requests that have been inactive > 30 days?

more than 30 days due to committers not having time to look at them, >>>>> but did eventually end up successfully being merged. >>>>> >>>>> I guess if this just ends up being a committer ping and reopening the >>>>> PR, it's fine

Re: auto closing pull requests that have been inactive > 30 days?

t;>> >>>> I guess if this just ends up being a committer ping and reopening the >>>> PR, it's fine, but I don't know if it really addresses the underlying >>>> issue. >>>> >>>> On Mon, Apr 18, 2016 at 2:02 PM, Reynol

Re: auto closing pull requests that have been inactive > 30 days?

;>> I guess if this just ends up being a committer ping and reopening the >>> PR, it's fine, but I don't know if it really addresses the underlying >>> issue. >>> >>> On Mon, Apr 18, 2016 at 2:02 PM, Reynold Xin >>> wrote: >>> &g

Re: auto closing pull requests that have been inactive > 30 days?

days due to committers not having time to look at them, >>> but did eventually end up successfully being merged. >>> >>> I guess if this just ends up being a committer ping and reopening the >>> PR, it's fine, but I don't know if it really a

Re: auto closing pull requests that have been inactive > 30 days?

ot having time to look at them, >> but did eventually end up successfully being merged. >> >> I guess if this just ends up being a committer ping and reopening the >> PR, it's fine, but I don't know if it really addresses the underlying >> issue. >> >&

Re: auto closing pull requests that have been inactive > 30 days?

gt; PR, it's fine, but I don't know if it really addresses the underlying > issue. > > On Mon, Apr 18, 2016 at 2:02 PM, Reynold Xin wrote: > > We have hit a new high in open pull requests: 469 today. While we can > > certainly get more review bandwidth, many of

Re: auto closing pull requests that have been inactive > 30 days?

t know if it really addresses the underlying > issue. > > On Mon, Apr 18, 2016 at 2:02 PM, Reynold Xin wrote: > > We have hit a new high in open pull requests: 469 today. While we can > > certainly get more review bandwidth, many of these are old and still open > > for oth

Re: auto closing pull requests that have been inactive > 30 days?

't know if it really addresses the underlying issue. On Mon, Apr 18, 2016 at 2:02 PM, Reynold Xin wrote: > We have hit a new high in open pull requests: 469 today. While we can > certainly get more review bandwidth, many of these are old and still open > for other reasons. Some are st

auto closing pull requests that have been inactive > 30 days?

We have hit a new high in open pull requests: 469 today. While we can certainly get more review bandwidth, many of these are old and still open for other reasons. Some are stale because the original authors have become busy and inactive, and some others are stale because the committers are not

[ANNOUNCE] New testing capabilities for pull requests

Hi All, For pull requests that modify the build, you can now test different build permutations as part of the pull request builder. To trigger these, you add a special phrase to the title of the pull request. Current options are: [test-maven] - run tests using maven and not sbt [test-hadoop1.0

Fwd: pull requests no longer closing by commit messages with "closes #xxxx"

FYI. -- Forwarded message -- From: John Greet (GitHub Staff) Date: Mon, Jun 8, 2015 at 5:50 PM Subject: Re: pull requests no longer closing by commit messages with "closes #" To: Reynold Xin Hi Reynold, The problem here is that the commits closing those pull req

Re: Pull Requests on github

its of system optimised natives and how to use them :-) > > > > > > https://github.com/apache/spark/pull/4448 > > > > > > However, it looks like there are a *lot* of outstanding PRs and that > this > > > is > > > just a mirror repository. > >

Re: Pull Requests on github

; > Best regards, > > Sam > > > > > > > > -- > > View this message in context: > > > http://apache-spark-developers-list.1001551.n3.nabble.com/Pull-Requests-on-github-tp10502.html > > Sent from the Apache Spark Developers List mailing list archive at

Re: Pull Requests on github

and that this > is > just a mirror repository. > > Will somebody please look at my PR and merge into the canonical source (and > let me know)? > > Best regards, > Sam > > > > -- > View this message in context: > http://apache-spark-developers-list.1001551.n3

Pull Requests on github

http://apache-spark-developers-list.1001551.n3.nabble.com/Pull-Requests-on-github-tp10502.html Sent from the Apache Spark Developers List mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.or

Re: Pull Requests

Can someone review patch #2309 (jira task SPARK-3178) Thanks On Mon, Oct 6, 2014 at 10:41 PM, Patrick Wendell wrote: > Hey Bill, > > Automated testing is just one small part of the process that performs > basic sanity checks on code. All patches need to be championed and > merged by a committer

Pull Requests

Once a PR has been tested and verified, when does it get pulled back into the trunk?

Re: Pull requests will be automatically linked to JIRA when submitted

ce to have for heavy JIRA users. >>>> > >>>> > Nick >>>> > >>>> > >>>> > >>>> > On Sun, Jul 20, 2014 at 12:50 PM, Patrick Wendell >>> > >>>> > wrote: >>>> > >>>> >&

Re: Pull requests will be automatically linked to JIRA when submitted

, 2014 at 12:50 PM, Patrick Wendell >>> > wrote: >>> > >>> >> Yeah it needs to have SPARK-XXX in the title (this is the format we >>> >> request already). It just works with small synchronization script I >>> >> wrote that we run every five minutes

Re: -1s on pull requests?

On Sun, Aug 3, 2014 at 4:35 PM, Nicholas Chammas wrote: > Include the commit hash in the "tests have started/completed" messages, so > that it's clear what code exactly is/has been tested for each test cycle. This is now captured in this JIRA issue

Re: Pull requests will be automatically linked to JIRA when submitted

> >> and Jenkins API: >> >> >> >> >> >> >> https://github.com/apache/spark/commit/49e472744951d875627d78b0d6e93cd139232929 >> >> >> >> - Patrick >> >> >> >> On Sun, Jul 20, 2014 at 8:06 AM, Nicholas Chamma

Re: Pull requests will be automatically linked to JIRA when submitted

>> > https://github.com/apache/spark/commit/49e472744951d875627d78b0d6e93cd139232929 > >> > >> - Patrick > >> > >> On Sun, Jul 20, 2014 at 8:06 AM, Nicholas Chammas > >> wrote: > >> > That's pretty neat. > >> >

Re: Pull requests will be automatically linked to JIRA when submitted

just need to put the issue ID (e.g. SPARK-1234) >> > anywhere in the pull request? >> > >> > Nick >> > >> > >> > On Sat, Jul 19, 2014 at 11:10 PM, Patrick Wendell >> > wrote: >> > >> >> Just a small note, today I com

Re: -1s on pull requests?

I think the build number is included in the SparkQA message, for example: https://github.com/apache/spark/pull/1788 The build number 17941 is in the URL "https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/17941/consoleFull";. Just need to be careful to match the number. Another so

Re: -1s on pull requests?

> > 1. Include the commit hash in the "tests have started/completed" > FYI: Looks like Xiangrui's already got a JIRA issue for this. SPARK-2622: Add Jenkins build numbers to SparkQA messages 2. "Pin" a message to the start or end of the PR Sho

Re: -1s on pull requests?

k has increased, there > are cases where pull requests get merged before all the review comments > have been addressed. This happens say when one committer points out a > problem with the pull request, and another committer doesn't see the > earlier comment and merges the PR before

Re: -1s on pull requests?

Sure thing - feel free to ping me off list if you need pointers. The script just does string concatenation and a curl to post the comment... I think it should be pretty accessible! - Patrick On Sun, Aug 3, 2014 at 9:12 PM, Nicholas Chammas wrote: > On Sun, Aug 3, 2014 at 11:29 PM, Patrick Wend

Re: -1s on pull requests?

On Sun, Aug 3, 2014 at 11:29 PM, Patrick Wendell wrote: Nick - Any interest in doing these? this is all doable from within the > spark repo itself because our QA harness scripts are in there: > > https://github.com/apache/spark/blob/master/dev/run-tests-jenkins > > If not, could you make a JIRA f

Re: -1s on pull requests?

> >1. Include the commit hash in the "tests have started/completed" >messages, so that it's clear what code exactly is/has been tested for > each >test cycle. > Great idea - I think this is easy to do given the current architecture. We already have access to the commit ID in the same s

Re: -1s on pull requests?

On Mon, Jul 21, 2014 at 4:44 PM, Kay Ousterhout wrote: > This also happens when something accidentally gets merged after the tests > have started but before tests have passed. > Some improvements to SparkQA could help with this. May I suggest: 1. Include the comm

Re: Pull requests will be automatically linked to JIRA when submitted

34) > > anywhere in the pull request? > > > > Nick > > > > > > On Sat, Jul 19, 2014 at 11:10 PM, Patrick Wendell > > wrote: > > > >> Just a small note, today I committed a tool that will automatically > >> mirror pull requests to JIRA

Re: -1s on pull requests?

the ASF github integration works. > > I've lately been using a custom-made tool to help review pull > requests. One thing I could do is add a feature here saying which > committers have said LGTM on a PR (vs the ones that have commented). > We could also indicate the latest test

Re: -1s on pull requests?

this happens accidentally some times. Unfortunately, we are not allowed to use those github hooks because of the way the ASF github integration works. I've lately been using a custom-made tool to help review pull requests. One thing I could do is add a feature here saying which committers

Re: -1s on pull requests?

-09-04-pull-requests-just-got-even-more-awesome/ On Mon, Jul 21, 2014 at 1:44 PM, Kay Ousterhout wrote: > Hi all, > > As the number of committers / contributors on Spark has increased, there > are cases where pull requests get merged before all the review comments > have been

-1s on pull requests?

Hi all, As the number of committers / contributors on Spark has increased, there are cases where pull requests get merged before all the review comments have been addressed. This happens say when one committer points out a problem with the pull request, and another committer doesn't se

Re: Pull requests will be automatically linked to JIRA when submitted

dell > wrote: > >> Just a small note, today I committed a tool that will automatically >> mirror pull requests to JIRA issues, so contributors will no longer >> have to manually post a pull request on the JIRA when they make one. >> >> It will create a "li

Re: Pull requests will be automatically linked to JIRA when submitted

That's pretty neat. How does it work? Do we just need to put the issue ID (e.g. SPARK-1234) anywhere in the pull request? Nick On Sat, Jul 19, 2014 at 11:10 PM, Patrick Wendell wrote: > Just a small note, today I committed a tool that will automatically > mirror pull requests to

Re: Pull requests will be automatically linked to JIRA when submitted

Awesome! On Saturday, July 19, 2014, Patrick Wendell wrote: > Just a small note, today I committed a tool that will automatically > mirror pull requests to JIRA issues, so contributors will no longer > have to manually post a pull request on the JIRA when they make one. > > I

Pull requests will be automatically linked to JIRA when submitted

Just a small note, today I committed a tool that will automatically mirror pull requests to JIRA issues, so contributors will no longer have to manually post a pull request on the JIRA when they make one. It will create a "link" on the JIRA and also make a comment to trigger an e-mail