<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 18, 2015 at 1:41 PM, Martin Graesslin <span dir="ltr"><<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Friday, September 18, 2015 2:14:00 PM CEST Jaroslaw Staniek wrote:<br>
> On 18 September 2015 at 14:00, Ben Cooksley <<a href="mailto:bcooksley@kde.org">bcooksley@kde.org</a>> wrote:<br>
> > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek <<a href="mailto:staniek@kde.org">staniek@kde.org</a>><br>
wrote:<br>
> >> On 18 September 2015 at 13:42, Boudhayan Gupta <<a href="mailto:bgupta@kde.org">bgupta@kde.org</a>> wrote:<br>
> >>> Ladies and gentlemen, as you read this mail <a href="http://github.com/kde" rel="noreferrer" target="_blank">github.com/kde</a> is being<br>
> >>> populated by the initial sync of all repositories.<br>
> >>><br>
> >>> Maybe someone should make a public announcement?<br>
> >>><br>
> >>> Shout out to Ben, he truly is a superhero.<br>
> >><br>
> >> Thanks a lot!<br>
> >> Is it possible to enable Issues support for a given project? (as I<br>
> >> said needed by the bountysource infra at least)<br>
> ><br>
> > From what I saw of the above consensus, issues and pull requests would<br>
> > be disabled as those should go through our usual infrastructure<br>
> > (<a href="http://todo.kde.org" rel="noreferrer" target="_blank">todo.kde.org</a> / <a href="http://bugs.kde.org" rel="noreferrer" target="_blank">bugs.kde.org</a> / <a href="http://reviewboard.kde.org" rel="noreferrer" target="_blank">reviewboard.kde.org</a>) - if there is a<br>
> > post otherwise i'd be happy to be pointed to it though?<br>
><br>
> I see what you mean but there was no discussion about this matter in<br>
> this thread at least.<br>
><br>
> For code I maintain I welcome:<br>
> - any form of patches even if they come via pull requests, just like<br>
> for me emailed patches are also better than no patches<br>
> - any form of donations for features -> for that Issues are needed<br>
><br>
> It's possible to fork these mirrors to get this support and I am doing<br>
> this now for a test in case of kreport.git.<br>
> <a href="https://github.com/staniek/kreport-1" rel="noreferrer" target="_blank">https://github.com/staniek/kreport-1</a><br>
><br>
> But again, please consider this as less controlled/predictable<br>
> activity - that forking will happen anyway, as this is the value of<br>
> github-based collaboration, and (IMHO) sense of our existence on<br>
> github.<br>
<br></div></div></blockquote><div>Issues can are disabled<br><br></div><div>Pull requests we can't disable.<br></div><div>However I've found this bot: <a href="http://nopullrequests.com/">http://nopullrequests.com/</a><br><br></div><div>that gets pull requests then automatically repsonds closing it.<br></div><div></div><div>Might be worth us doing, saying "go to <a href="http://reviewboard.kde.org">reviewboard.kde.org</a>"<br></div><div><br></div><div>Just as a reminder<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">
</div></div>We must be extremely careful to not proprietarize our development<br>
infrastructure. Accepting the one pull request is no problem, but once all<br>
development happens through pull request, we have moved our development<br>
infrastructure to a proprietary platform and run in a vendor-lock-in<br>
situation.<br>
<br>
If you want to accept pull requests think about what it means. This is quite<br>
different to mail: mail is not a single vendor lock-in and also not<br>
proprietary.<br>
<br>
My suggestion is that it's ok to accept pull request from new contributors,<br>
but at the same time tell them how to contribute in future. That it's an<br>
exception and not the rule.<br>
<br>
I also suggest that we update our README(.md) files and point out how to<br>
contribute.<br>
<br>
Cheers<br>
<span class=""><font color="#888888">Martin</font></span><br>_______________________________________________<br>
kde-community mailing list<br>
<a href="mailto:kde-community@kde.org">kde-community@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-community" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-community</a><br></blockquote></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 18, 2015 at 1:41 PM, Martin Graesslin <span dir="ltr"><<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Friday, September 18, 2015 2:14:00 PM CEST Jaroslaw Staniek wrote:<br>
> On 18 September 2015 at 14:00, Ben Cooksley <<a href="mailto:bcooksley@kde.org">bcooksley@kde.org</a>> wrote:<br>
> > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek <<a href="mailto:staniek@kde.org">staniek@kde.org</a>><br>
wrote:<br>
> >> On 18 September 2015 at 13:42, Boudhayan Gupta <<a href="mailto:bgupta@kde.org">bgupta@kde.org</a>> wrote:<br>
> >>> Ladies and gentlemen, as you read this mail <a href="http://github.com/kde" rel="noreferrer" target="_blank">github.com/kde</a> is being<br>
> >>> populated by the initial sync of all repositories.<br>
> >>><br>
> >>> Maybe someone should make a public announcement?<br>
> >>><br>
> >>> Shout out to Ben, he truly is a superhero.<br>
> >><br>
> >> Thanks a lot!<br>
> >> Is it possible to enable Issues support for a given project? (as I<br>
> >> said needed by the bountysource infra at least)<br>
> ><br>
> > From what I saw of the above consensus, issues and pull requests would<br>
> > be disabled as those should go through our usual infrastructure<br>
> > (<a href="http://todo.kde.org" rel="noreferrer" target="_blank">todo.kde.org</a> / <a href="http://bugs.kde.org" rel="noreferrer" target="_blank">bugs.kde.org</a> / <a href="http://reviewboard.kde.org" rel="noreferrer" target="_blank">reviewboard.kde.org</a>) - if there is a<br>
> > post otherwise i'd be happy to be pointed to it though?<br>
><br>
> I see what you mean but there was no discussion about this matter in<br>
> this thread at least.<br>
><br>
> For code I maintain I welcome:<br>
> - any form of patches even if they come via pull requests, just like<br>
> for me emailed patches are also better than no patches<br>
> - any form of donations for features -> for that Issues are needed<br>
><br>
> It's possible to fork these mirrors to get this support and I am doing<br>
> this now for a test in case of kreport.git.<br>
> <a href="https://github.com/staniek/kreport-1" rel="noreferrer" target="_blank">https://github.com/staniek/kreport-1</a><br>
><br>
> But again, please consider this as less controlled/predictable<br>
> activity - that forking will happen anyway, as this is the value of<br>
> github-based collaboration, and (IMHO) sense of our existence on<br>
> github.<br>
<br>
</div></div>We must be extremely careful to not proprietarize our development<br>
infrastructure. Accepting the one pull request is no problem, but once all<br>
development happens through pull request, we have moved our development<br>
infrastructure to a proprietary platform and run in a vendor-lock-in<br>
situation.<br>
<br>
If you want to accept pull requests think about what it means. This is quite<br>
different to mail: mail is not a single vendor lock-in and also not<br>
proprietary.<br>
<br>
My suggestion is that it's ok to accept pull request from new contributors,<br>
but at the same time tell them how to contribute in future. That it's an<br>
exception and not the rule.<br>
<br>
I also suggest that we update our README(.md) files and point out how to<br>
contribute.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Martin</font></span><br>_______________________________________________<br>
kde-community mailing list<br>
<a href="mailto:kde-community@kde.org">kde-community@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-community" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-community</a><br></blockquote></div><br></div>