[kde-community] Official KDE mirror on github

[Martin Graesslin]

On Friday, September 18, 2015 2:14:00 PM CEST Jaroslaw Staniek wrote:
> On 18 September 2015 at 14:00, Ben Cooksley <bcooksley at kde.org> wrote:
> > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek <staniek at kde.org> 
wrote:
> >> On 18 September 2015 at 13:42, Boudhayan Gupta <bgupta at kde.org> wrote:
> >>> Ladies and gentlemen, as you read this mail github.com/kde is being
> >>> populated by the initial sync of all repositories.
> >>> 
> >>> Maybe someone should make a public announcement?
> >>> 
> >>> Shout out to Ben, he truly is a superhero.
> >> 
> >> Thanks a lot!
> >> Is it possible to enable Issues support for a given project? (as I
> >> said needed by the bountysource infra at least)
> > 
> > From what I saw of the above consensus, issues and pull requests would
> > be disabled as those should go through our usual infrastructure
> > (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a
> > post otherwise i'd be happy to be pointed to it though?
> 
> I see what you mean but there was no discussion about this matter in
> this thread at least.
> 
> For code I maintain I welcome:
> - any form of patches even if they come via pull requests, just like
> for me emailed patches are also better than no patches
> - any form of donations for features -> for that Issues are needed
> 
> It's possible to fork these mirrors to get this support and I am doing
> this now for a test in case of kreport.git.
> https://github.com/staniek/kreport-1
> 
> But again, please consider this as less controlled/predictable
> activity - that forking will happen anyway, as this is the value of
> github-based collaboration, and (IMHO) sense of our existence on
> github.

We must be extremely careful to not proprietarize our development 
infrastructure. Accepting the one pull request is no problem, but once all 
development happens through pull request, we have moved our development 
infrastructure to a proprietary platform and run in a vendor-lock-in 
situation.

If you want to accept pull requests think about what it means. This is quite 
different to mail: mail is not a single vendor lock-in and also not 
proprietary.

My suggestion is that it's ok to accept pull request from new contributors, 
but at the same time tell them how to contribute in future. That it's an 
exception and not the rule.

I also suggest that we update our README(.md) files and point out how to 
contribute.

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/20150918/138c9782/attachment.sig>