<br><br>On Saturday, 19 September 2015, Martin Graesslin <<a href="mailto:mgraesslin@kde.org">mgraesslin@kde.org</a>> wrote:<br>> On Friday, September 18, 2015 5:29:01 PM CEST Albert Vaca wrote:<br>>> From my experience, I was already mirroring KDE Connect in Github and I've<br>>> received valuable patches there. That's a big enough reason for me to want<br>>> Github's pull requests (and to spend 15 minutes learning how to use them),<br>>> but I understand not everybody wants to learn a new and non-free tool.<br>><br>> I'm subscribed to kde-connects review requests for reviewboard. How am I as an<br>> interested developer able to follow the code review for github pull requests<br>> if I don't want to use them?<br>><br>> Basically by the decision to opt-in for pull requests you force the complete<br>> team to follow them. Otherwise not-reviewed code gets in.<br><br>What I meant is that review is handled in a free tool. See I asked about deprecating review board not once to have on tool for the task -phab, for a reason. <br>Github is just like Gmail in this workflow, even less because in my book you can't keep using it for regular contributions -this is a knowledge you get after the first *motivating* success of approved patches.<br>Even at single subproject level fellow contributors don't see a downside, only a chance for more patches. <br><br><br>><br>> We really need to think in the big picture of what means this to KDE. We<br>> shouldn't go the "selfish" road and think of your own project. By allowing<br>> github pull-requests we are pushing out the contributors who don't want to use<br>> it. You make it impossible for those contributors to comment on review<br>> requests, thus you have split the development.<br>><br><br>See above, these are not the discussed bits. <br><br>> This is scary. Please don't think "selfish". Let people create the pull<br>> request and answer it with:<br>> "Sorry we do not support git hub pull request. To submit code please use<br>> <a href="http://reviewboard.kde.org">reviewboard.kde.org</a>. Here's how you do it..."<br><br><br>And can I do better than that 'slap in the face', I am free to do that.<br><br><br><br><br>><br>> The point is we want to get to the people on github. That's why we mirror.<br>> It's not about getting pull requests. We want the people! They already spent<br>> the effort to create the patch, they will spent the additional time to get to<br>> reviewboard of phabricator in future. I have so often got patches on bugzilla<br>> and it never was a problem to tell them "please use reviewboard for the patch<br>> submission as the UI is more streamlined for code review". We always got the<br>> patch into reviewboard. The aim of the people is not to use pull requests, the<br>> aim is to submit their patch!<br>><br><br>This is you talking to them in person. Quite better thing than automatic closing.<br><br>> Cheers<br>> Martin<br>><br><br>-- <br>regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a><br>