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