<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 19, 2015 at 1:12 PM, Martin Graesslin <span dir="ltr"><<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">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>
</span>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" rel="noreferrer" target="_blank">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></blockquote><div><br></div><div>+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></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Martin<br>
</font></span><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" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-community</a><br></blockquote></div><br></div><div class="gmail_extra">Cheers,<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>Shantanu Tushar    (UTC +0530)<br><a href="http://shantanu.io" target="_blank">shantanu.io</a></div></div></div>
</div></div>