[kde-community] Write our own pull request bot?

Martin Klapetek martin.klapetek at gmail.com
Sat Sep 19 18:05:01 UTC 2015

On Sat, Sep 19, 2015 at 1:55 PM, Eike Hein <hein at kde.org> wrote:

> On 09/19/2015 07:49 PM, Martin Klapetek wrote:
> > We wouldn't get no lock-in though. Not even remotely. It will simply
> > be another path for an incoming patch. If the patch in question ends
> > up on Phabricator and gets reviewed on Phabricator and merged from
> > Phabricator, it is no different than the patch initially arriving by
> email,
> > irc/paste etc. Just a different input route.
> That doesn't address Sune's concern though. If you
> get a patch by email you can reply by email; the
> comm channel stays the same. Ditto IRC. If you file
> a pull req on GitHub and it gets imported into Phab
> which you don't have an account for yet and can't
> interact with using the same client (git, or the
> website you were using) you were already using, you
> are inserting a hump in that. The requestee wouldn't
> even get emails about review comments unless the bot
> does complicated steps like trying to use the GitHub
> API to read out an account email (if it even can).

You'd have the email from the commit already though.

The bot could be extended (over time, even) to be capable of posting
comments back, even a simple "there's a new comment on your patch
at <link>". If the user will care, s/he will care. If not, then it ends up
as hundreds of already unattended patches on reviewboard, where the
original submitter didn't respond to questions and/or didn't update the

A concrete example: https://git.reviewboard.kde.org/r/105932/

Patch from 2012 with open questions/issues from a newcomer(?), left
unattended. Having the same on Phabricator with the source being github
would be no different, would it? And there _will_ be patches left to rot
on Phabricator anyway, just like hundreds of them right now on Reviewboard.

Auto-import is a slight improvement over auto-reject
> on the "it snubs people" front, but it's not a big
> one and it creates a lot of practical concerns. Some
> of those could be addressed with more code, if some-
> one writes it - but then it should be written and
> tested and evluated before we enable that channel.

Sure. It's _a_ solution. I don't claim it's a perfect one, but it is one.

Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20150919/5738a26b/attachment.html>

More information about the kde-community mailing list