On Sat, Sep 19, 2015 at 1:55 PM, Eike Hein <[email protected]> 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
_______________________________________________ kde-community mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-community
