Am Montag, 17. August 2015, 07:46:44 CEST schrieb Martin Graesslin: > Hi community,
Hello Martin, hi community, > over the last months I observed the following: > * people not finding our git repositories > * people being surprised that our code is not on github > * some projects starting to use github in addition to our own infrastructure > > Whether we like it or not, github has become a place to look for free > software nowadays and if you are not on github your software just doesn't > exist. Given that we can say KDE doesn't produce source code because we are > not on github. > > Other projects have an official mirror (see e.g. [1]) which solves the three > points I have listed above. > > I suggest that we: > * introduce an official mirror for all KDE repositories on github > * replace all existing (non-official) clones > * disallow pull-requests on github to not replace our development model by a > proprietary platform. I like to summarize a key conflict the by now not yet announced github.com KDE mirror triggered according to my understanding of the existing sub threads around it. I don´t want to start a new thread, so I just use a changed subject below the top of this thread. In my perception the arguments are mostly around whether pull-requests are allowed or not while however some do not like to use github.com even a just a mirror. I want to bring this more in context of the current values the KDE project gave itself in the KDE Manifesto. Pro pull requests¹: > * Inclusivity to ensure that all people are welcome to join us and > participate; There were arguments that allowing github.com pull requests invites more people to contribute. On the other hand there were arguments that it is not a problem to educate people to contribute their patch via KDE infrastructure as people want to contribute the patch not the process they used to submit it. Against pull requests¹: > * Free Software to ensure the result of our work is available to all people > for all time; But one can argue that even if hosted on github.com the projects are still free software. Yet allowing pull requests is at least if not endorsing allowing non-free development process tools. Also this may be about > Open Governance to ensure engagement in our leadership and decision > processes; but then pull requests are openly visible as well. Well as long as github.com doesn´t decide to stop hosting those. ¹ https://manifesto.kde.org/ In the commitments under technical requirements I see two points against pull requests. I am a bit unsure from what of the base principles these are derived from. Can someone more familiar with the manifesto shed a light on this? They are²: > All source materials are hosted on infrastructure available to and writable > by all KDE contributor accounts For putting anything on github.com a KDE contributor account cannot be used. One needs a github.com account. Any write access to the github.com stuff needs a github.com account, even just for closing a pull request. > Online services associated with the project are either hosted on KDE > infrastructure or have an action plan that ensures continuity which is > approved by the KDE system administration team For this one can argue: But the stuff primarily is on our own infrastructure. But that is only true for the source code. All pull requests, and if enabled, reported issues are hosted by github.com. And github.com as someone in this thread already pointed out does not give *any* guarentee about continuity *whatsoever*. ² https://manifesto.kde.org/commitments.html So I ask the constructive question: How to address the concerns about inclusivity without sacrificing on freedom and free software ideals? How to balance between the different values of the manifesto or even better find a way to address them all? Of course changing values of the manifesto, evolving it as Vishesh said, is also possible, yet, I think like with a constitution of a democratic state any changes to the manifesto needs really strong and fundamental reasons. It needs seeing beyond the own point of view towards the general wellfare of everyone involved. One issue that would need to be dealt with regarding any write access to (parts of) the official github.com KDE presence would be ensuring continuity. I know there is the github-backup tool by Joey Hess packaged in Debian³: > github-backup is a simple tool you run in a git repository you cloned from > GitHub. It backs up everything GitHub publishes about the repository, > including branches, tags, other forks, issues, comments, wikis, milestones, > pull requests, watchers, and stars. ³ http://github.com/joeyh/github-backup Yet, what amount of effort would be required to host them on KDE infrastructure in case github.com terminates its service? An even better way would be to automatically forward / move any github.com requests to KDE infrastructure, but I bet this needs quite an amount of scripting effort. Of course that wouldn´t solve the more generic concerns about endorsing non- free development tools. Another approach would be: How can KDE infrastructure evolve into something that makes contributing as easy or even easier than github.com? What needs to be improved in order to invite github.com users onto KDE´s own infrastructure? Ciao, -- Martin _______________________________________________ kde-community mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-community
