+1 On Sat, 19 Sep 2015 14:05:01 -0400 Martin Klapetek <martin.klape...@gmail.com> wrote:
> On Sat, Sep 19, 2015 at 1:55 PM, Eike Hein <h...@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 -- Rajeev Bhatta <techie.raj...@yahoo.in> _______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community