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

[Martin Klapetek]

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
patch.

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.

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