On Fri, Sep 18, 2015 at 1:41 PM, Martin Graesslin <mgraess...@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 <bcooks...@kde.org> wrote: > > > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek <stan...@kde.org> > wrote: > > >> On 18 September 2015 at 13:42, Boudhayan Gupta <bgu...@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@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > On Fri, Sep 18, 2015 at 1:41 PM, Martin Graesslin <mgraess...@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 <bcooks...@kde.org> wrote: > > > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek <stan...@kde.org> > wrote: > > >> On 18 September 2015 at 13:42, Boudhayan Gupta <bgu...@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@kde.org > https://mail.kde.org/mailman/listinfo/kde-community >
_______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community