[kde-community] Official KDE mirror on github

Martin Graesslin mgraesslin at kde.org
Sat Sep 19 09:30:52 BST 2015


On Saturday, September 19, 2015 10:25:05 AM CEST Jaroslaw Staniek wrote:
> On Saturday, 19 September 2015, Shantanu Tushar Jha <shantanu at kde.org>
> 
> wrote:
> > On Sat, Sep 19, 2015 at 1:12 PM, Martin Graesslin <mgraesslin at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20150919/d97b7b85/attachment.sig>


More information about the kde-community mailing list