spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Chammas <nicholas.cham...@gmail.com>
Subject Re: Handling stale PRs
Date Tue, 26 Aug 2014 18:37:28 GMT
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 <rosenville@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).
>  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 JIRAs, Jenkins statuses, a quick preview of
> the last comment, etc.
>
> - Pull requests are auto-classified based on which components they modify
> (by looking at the diff).
>
> - From the app’s own internal database of PRs, we can build dashboards to
> find “abandoned” PRs, graph average time to first review, etc.
>
> - Since we authenticate users with GitHub, we can enable administrative
> functions via this dashboard (e.g. “assign this PR to me”, “vote to close
> in the weekly auto-close commit”, etc.
>
> Right now, I’ve implemented GItHub OAuth support and code to update the
> issues database using the GitHub API.  Because we have access to the full
> API, it’s pretty easy to do fancy things like parsing the reason for
> Jenkins failure, etc.  You could even imagine some fancy mashup tools to
> pull up JIRAs and pull requests side-by in iframes.
>
> After I hack on this a bit more, I plan to release a public preview
> version; if we find this tool useful, I’ll clean it up and open-source the
> app so folks can contribute to it.
>
> - Josh
>
> On August 26, 2014 at 8:16:46 AM, Nicholas Chammas (
> nicholas.chammas@gmail.com) wrote:
>
> On Tue, Aug 26, 2014 at 2:02 AM, Patrick Wendell <pwendell@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 a culture would set Spark apart from other
> projects in a great way.
>
> 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 ideas:
>
>
> I've added myself as a watcher on those 2 INFRA issues. Sucks that the
> only
> solution on offer right now requires basically polluting the commit
> history.
>
> Short of moving Spark's repo to a non-ASF-managed GitHub account, do you
> think another bot could help us manage the number of stale PRs?
>
> I'm thinking a solution as follows might be very helpful:
>
> - Extend Spark QA / Jenkins to run on a weekly schedule and check for
> stale PRs. Let's say a stale PR is an open one that hasn't been updated in
> N months.
> - Spark QA maintains a list of known committers on its side.
> - During its weekly check of stale PRs, Spark QA takes the following
> action:
> - If the last person to comment on a PR was a committer, post to the
> PR asking for an update from the contributor.
> - If the last person to comment on a PR was a contributor, add the PR
> to a list. Email this list of *hanging PRs* out to the dev list on a
> weekly basis and ask committers to update them.
> - If the last person to comment on a PR was Spark QA asking the
> contributor to update it, then add the PR to a list. Email this
> list of *abandoned
> PRs* to the dev list for the record (or for closing, if that becomes
> possible in the future).
>
> This doesn't solve the problem of not being able to close PRs, but it does
> help make sure no PR is left hanging for long.
>
> What do you think? I'd be interested in implementing this solution if we
> like it.
>
> Nick
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message