[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-community
Subject: Re: [kde-community] Write our own pull request bot?
From: Martin Klapetek <martin.klapetek () gmail ! com>
Date: 2015-09-19 18:05:01
Message-ID: CAPLgePraN7F1M7-TPdE4u6Y9UTfUJan1k5-2X0c=dwxrC1nGQw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Sep 19, 2015 at 1:55 PM, Eike Hein <hein@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
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 19, 2015 \
at 1:55 PM, Eike Hein <span dir="ltr"><<a href="mailto:hein@kde.org" \
target="_blank">hein@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span \
class="">On 09/19/2015 07:49 PM, Martin Klapetek wrote:<br> > We wouldn't get \
no lock-in though. Not even remotely. It will simply<br> > be another path for an \
incoming patch. If the patch in question ends<br> > up on Phabricator and gets \
reviewed on Phabricator and merged from<br> > Phabricator, it is no different than \
the patch initially arriving by email,<br> > irc/paste etc. Just a different input \
route.<br> <br>
</span>That doesn't address Sune's concern though. If you<br>
get a patch by email you can reply by email; the<br>
comm channel stays the same. Ditto IRC. If you file<br>
a pull req on GitHub and it gets imported into Phab<br>
which you don't have an account for yet and can't<br>
interact with using the same client (git, or the<br>
website you were using) you were already using, you<br>
are inserting a hump in that. The requestee wouldn't<br>
even get emails about review comments unless the bot<br>
does complicated steps like trying to use the GitHub<br>
API to read out an account email (if it even \
can).<br></blockquote><div><br></div><div>You'd have the email from the commit \
already though.</div><div><br></div><div>The bot could be extended (over time, even) \
to be capable of posting</div><div>comments back, even a simple "there's a \
new comment on your patch</div><div>at <link>". If the user will care, \
s/he will care. If not, then it ends up</div><div>as hundreds of already unattended \
patches on reviewboard, where the</div><div>original submitter didn't respond to \
questions and/or didn't update the</div><div>patch.</div><div><br></div><div>A \
concrete example: <a \
href="https://git.reviewboard.kde.org/r/105932/">https://git.reviewboard.kde.org/r/105932/</a></div><div><br></div><div>Patch \
from 2012 with open questions/issues from a newcomer(?), left</div><div>unattended. \
Having the same on Phabricator with the source being github</div><div>would be no \
different, would it? And there _will_ be patches left to rot</div><div>on Phabricator \
anyway, just like hundreds of them right now on \
Reviewboard.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Auto-import is a slight improvement over auto-reject<br>
on the "it snubs people" front, but it's not a big<br>
one and it creates a lot of practical concerns. Some<br>
of those could be addressed with more code, if some-<br>
one writes it - but then it should be written and<br>
tested and evluated before we enable that \
channel.<br></blockquote><div><br></div><div>Sure. It's _a_ solution. I don't \
claim it's a perfect one, but it is \
one.</div><div><br></div></div><div>Cheers</div>-- <br><div \
class="gmail_signature"><div><span style="color:rgb(102,102,102)">Martin Klapetek | \
KDE Developer</span></div></div> </div></div>
[Attachment #6 (text/plain)]
_______________________________________________
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic