<br><br>On Saturday, 19 September 2015, Shantanu Tushar Jha <<a href="mailto:shantanu@kde.org">shantanu@kde.org</a>> wrote:<br>><br>><br>> On Sat, Sep 19, 2015 at 1:12 PM, Martin Graesslin <<a href="mailto:mgraesslin@kde.org">mgraesslin@kde.org</a>> wrote:<br>>><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>>> 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>>> 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>>> 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>> +1 to that. And adding to it, IMO the most important thing here is consistency. The last thing we want to have is newcomers getting confused "erm, so for this KDE project do I use reviewboard? or do I create a pull request?".<br>>  <br><br><br>But you just got confused by the claim from Martin, use of github reviews isn't proposed also because our repos are readonly there!<br>Please read what I propose not strawmans...<br><br>>><br>>> Cheers<br>>> Martin<br>>><br>>> _______________________________________________<br>>> kde-community mailing list<br>>> <a href="mailto:kde-community@kde.org">kde-community@kde.org</a><br>>> <a href="https://mail.kde.org/mailman/listinfo/kde-community">https://mail.kde.org/mailman/listinfo/kde-community</a><br>><br>> Cheers,<br>><br>> --<br>> Shantanu Tushar    (UTC +0530)<br>> <a href="http://shantanu.io">shantanu.io</a><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>