[kde-community] Official KDE mirror on github in the light of the KDE manifesto
martin at lichtvoll.de
Sat Sep 19 12:05:01 UTC 2015
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. ) 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
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
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
but then pull requests are openly visible as well. Well as long as github.com
doesn´t decide to stop hosting those.
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?
> 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
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
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.
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
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?
More information about the kde-community