Shout-out to Michael and other Spark SQL contributors for really trimming
down the number of open/stale Spark SQL PRs
https://spark-prs.appspot.com/#sql.
As of right now, the least recently updated open Spark SQL PR goes back
only 11 days.
Nice work!
Nick
On Mon Dec 08 2014 at 2:58:08 PM
I recently came across this blog post, which reminded me of this thread.
How to Discourage Open Source Contributions
http://danluu.com/discourage-oss/
We are currently at 320+ open PRs, many of which haven't been updated in
over a month. We have quite a few PRs that haven't been touched in 3-5
Thank you for pointing this out, Nick. I know that for myself and my
colleague who are starting to contribute to Spark, it¹s definitely
discouraging to have fixes sitting in the pipeline. Could you recommend
any other ways that we can facilitate getting these PRs accepted? Clean,
well-tested code
Things that help:
- Be persistent. People are busy, so just ping them if there’s been no
response for a couple of weeks. Hopefully, as the project continues to
develop, this will become less necessary.
- Only ping reviewers after test results are back from Jenkins. Make
sure all
On Tue, Aug 26, 2014 at 2:02 AM, Patrick Wendell pwend...@gmail.com wrote:
it's actually precedurally difficult for us to close pull requests
Just an FYI: Seems like the GitHub-sanctioned work-around to having
issues-only permissions is to have a second, issues-only repository
On Tue, Aug 26, 2014 at 2:21 PM, Josh Rosen rosenvi...@gmail.com wrote:
Last weekend, I started hacking on a Google App Engine app for helping
with pull request review (screenshot: http://i.imgur.com/wwpZKYZ.png).
BTW Josh, how can we stay up-to-date on your work on this tool? A JIRA
issue,
Wonder if it would make sense to introduce a notion of 'Reviewers' as an
intermediate tier to help distribute the load? While anyone can review and
comment on an open PR, reviewers would be able to say aye or nay subject to
confirmation by a committer?
Thanks,
Nishkam
On Wed, Aug 27, 2014 at
Hey Nishkam,
To some extent we already have this process - many community members
help review patches and some earn a reputation where committer's will
take an LGTM from them seriously. I'd be interested in seeing if any
other projects recognize people who do this.
- Patrick
On Wed, Aug 27,
I have a very simple dashboard running at http://spark-prs.appspot.com/.
Currently, this mirrors the functionality of Patrick’s github-shim, but it
should be very easy to extend with other features.
The source is at https://github.com/databricks/spark-pr-dashboard (pull
requests and issues
Alright! That was quick. :)
On Wed, Aug 27, 2014 at 6:48 PM, Josh Rosen rosenvi...@gmail.com wrote:
I have a very simple dashboard running at http://spark-prs.appspot.com/.
Currently, this mirrors the functionality of Patrick’s github-shim, but it
should be very easy to extend with other
I see. Yeah, it would be interesting to know if any other project has
considered formalizing this notion. It may also enable assignment of
reviews (potentially automated using Josh's system) and maybe anonymity as
well? On the downside, it isn't easily implemented and probably doesn't
come without
Hey Nicholas,
Thanks for bringing this up. There are a few dimensions to this... one is
that it's actually precedurally difficult for us to close pull requests.
I've proposed several different solutions to ASF infra to streamline the
process, but thus far they haven't been open to any of my
On 08/26/2014 04:57 AM, Sean Owen wrote:
On Tue, Aug 26, 2014 at 7:02 AM, Patrick Wendell pwend...@gmail.com wrote:
Most other ASF projects I know just ignore these patches. I'd prefer if we
Agree, this drives me crazy. It kills part of JIRA's usefulness. Spark
is blessed/cursed with
, overlapping Jira issues, we probably have to create a meta issue
and assign resources to fix it. I don't mind helping with that also.
-
--
Madhu
https://www.linkedin.com/in/msiddalingaiah
--
View this message in context:
http://apache-spark-developers-list.1001551.n3.nabble.com/Handling-stale
- Original Message -
Another thing is that we should, IMO, err on the side of explicitly saying
no or not yet to patches, rather than letting them linger without
attention. We do get patches where the user is well intentioned, but it is
Completely agree. The solution is partly
On Tue, Aug 26, 2014 at 2:02 AM, Patrick Wendell pwend...@gmail.com wrote:
I'd prefer if we took the approach of politely explaining why in the
current form the patch isn't acceptable and closing it (potentially w/ tips
on how to improve it or narrow the scope).
Amen to this. Aiming for such
Last weekend, I started hacking on a Google App Engine app for helping with
pull request review (screenshot: http://i.imgur.com/wwpZKYZ.png). Some of my
basic goals (not all implemented yet):
- Users sign in using GitHub and can browse a list of pull requests, including
links to associated
OK, that sounds pretty cool.
Josh,
Do you see this app as encompassing or supplanting the functionality I
described as well?
Nick
On Tue, Aug 26, 2014 at 2:21 PM, Josh Rosen rosenvi...@gmail.com wrote:
Last weekend, I started hacking on a Google App Engine app for helping
with pull request
Sure; App Engine supports cron and sending emails. We can configure the app
with Spark QA’s credentials in order to allow it to post comments on issues,
etc.
- Josh
On August 26, 2014 at 11:38:08 AM, Nicholas Chammas
(nicholas.cham...@gmail.com) wrote:
OK, that sounds pretty cool.
Josh,
By the way, as a reference point, I just stumbled across the Discourse
GitHub project and their list of pull requests
https://github.com/discourse/discourse/pulls looks pretty neat.
~2,200 closed PRs, 6 open. Least recently updated PR dates to 8 days ago.
Project started ~1.5 years ago.
Dunno
might be a reason for their
success.
-
--
Madhu
https://www.linkedin.com/in/msiddalingaiah
--
View this message in context:
http://apache-spark-developers-list.1001551.n3.nabble.com/Handling-stale-PRs-tp8015p8061.html
Sent from the Apache Spark Developers List mailing list archive
Check this out:
https://github.com/apache/spark/pulls?q=is%3Aopen+is%3Apr+sort%3Aupdated-asc
We're hitting close to 300 open PRs. Those are the least recently updated
ones.
I think having a low number of stale (i.e. not recently updated) PRs is a
good thing to shoot for. It doesn't leave
Hey Nicholas,
In general we've been looking at these periodically (at least I have) and
asking people to close out of date ones, but it's true that the list has gotten
fairly large. We should probably have an expiry time of a few months and close
them automatically. I agree that it's daunting
23 matches
Mail list logo
