[kde-community] Official KDE mirror on github

[Martin Graesslin]

On Friday, September 18, 2015 1:53:36 PM CEST David Edmundson wrote:
> On Fri, Sep 18, 2015 at 1:41 PM, Martin Graesslin <mgraesslin at kde.org>
> 
> wrote:
> > 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.
> > 
> > Issues can are disabled
> 
> Pull requests we can't disable.
> However I've found this bot: http://nopullrequests.com/
> 
> that gets pull requests then automatically repsonds closing it.
> Might be worth us doing, saying "go to reviewboard.kde.org"

Oh I think we should add that bot. I thought pull-requests are disabled by 
default. I certainly don't want to check all the repos I maintain for pull-
requests.

Cheers
Martin

> 
> Just as a reminder
> 
> > 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
> > _______________________________________________
> > kde-community mailing list
> > kde-community at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-community
> 
> On Fri, Sep 18, 2015 at 1:41 PM, Martin Graesslin <mgraesslin at kde.org>
> 
> wrote:
> > 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
> > _______________________________________________
> > kde-community mailing list
> > kde-community at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-community
-------------- 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/ab22191e/attachment.sig>