On 18 September 2015 at 14:17, Ben Cooksley <[email protected]> wrote: > On Sat, Sep 19, 2015 at 12:14 AM, Jaroslaw Staniek <[email protected]> wrote: >> On 18 September 2015 at 14:00, Ben Cooksley <[email protected]> wrote: >>> On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek <[email protected]> wrote: >>>> On 18 September 2015 at 13:42, Boudhayan Gupta <[email protected]> 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. > > The decision isn't mine, it's the community's decision.
I know :) > I've already > added a note suggesting people submit patches on Reviewboard. > Don't we slowly drop support for Reviewboard? (even I am still not sure how to correctly update phabricator diff from command line) > For a decision on those two points, i'd welcome pointers to where that > was made in the above thread - or the opening of a new thread on those > topics. @all I think this is still the very same thread "KDE mirrored on github". 1. A friendly bot is a good idea. Friendly i.e. not saying that "you're doing bad thing using github". But if I was external contributor I'd find rejecting my carefully crafted patch rather offensive. Couldn't the link to the patch be sent by email to a right mailing list? 2. Regarding the issues/pull requests - nobody agreed/disagreed to my proposal. Is anyone against an *opt-in* possibility of enabling Issues and/or Pull Requests for a given mirrored repo? Opt-in by maintainer of the patches. We can easily draft a policy if someone is afraid. Until we have "free" bountysource-like infra, I do need github Issues. I also work with bountysource so they find a way to better support bugs.kde.org; for now one can paste the url and it works but issues "for adoption" are not listed. Thanks again! PS: Also I think that I don't spend time on projects to educate people that they shouldn't use github. I am not competing in github's businesses. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek _______________________________________________ kde-community mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-community
