[kde-community] Official KDE mirror on github

[David Edmundson]

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"

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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20150918/187f2a43/attachment.htm>