On Saturday, September 19, 2015 10:25:05 AM CEST Jaroslaw Staniek wrote: > On Saturday, 19 September 2015, Shantanu Tushar Jha <shant...@kde.org> > > wrote: > > On Sat, Sep 19, 2015 at 1:12 PM, Martin Graesslin <mgraess...@kde.org> > > wrote: > >> On Friday, September 18, 2015 5:29:01 PM CEST Albert Vaca wrote: > >> > From my experience, I was already mirroring KDE Connect in Github and > > I've > > >> > received valuable patches there. That's a big enough reason for me to > > want > > >> > Github's pull requests (and to spend 15 minutes learning how to use > > them), > > >> > but I understand not everybody wants to learn a new and non-free tool. > >> > >> I'm subscribed to kde-connects review requests for reviewboard. How am I > > as an > > >> interested developer able to follow the code review for github pull > > requests > > >> if I don't want to use them? > >> > >> Basically by the decision to opt-in for pull requests you force the > > complete > > >> team to follow them. Otherwise not-reviewed code gets in. > >> > >> We really need to think in the big picture of what means this to KDE. We > >> shouldn't go the "selfish" road and think of your own project. By > > allowing > > >> github pull-requests we are pushing out the contributors who don't want > > to use > > >> it. You make it impossible for those contributors to comment on review > >> requests, thus you have split the development. > >> > >> This is scary. Please don't think "selfish". Let people create the pull > >> request and answer it with: > >> "Sorry we do not support git hub pull request. To submit code please use > >> reviewboard.kde.org. Here's how you do it..." > >> > >> The point is we want to get to the people on github. That's why we > > mirror. > > >> It's not about getting pull requests. We want the people! They already > > spent > > >> the effort to create the patch, they will spent the additional time to > > get to > > >> reviewboard of phabricator in future. I have so often got patches on > > bugzilla > > >> and it never was a problem to tell them "please use reviewboard for the > > patch > > >> submission as the UI is more streamlined for code review". We always got > > the > > >> patch into reviewboard. The aim of the people is not to use pull > > requests, the > > >> aim is to submit their patch! > > > > +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?". > > > > But you just got confused by the claim from Martin, use of github reviews > isn't proposed also because our repos are readonly there! > Please read what I propose not strawmans...
I replied to Albert and Albert said he wants to do code-review through github (and already does so). So no it's not strawman. If we allow pull requests we move part of our code-review infrastructure to github. Period! If we allow github we exclude everyone in the sub project from reviewing patches who don't want to use github. Cheers Martin
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community