[kde-community] Official KDE mirror on github in the light of the KDE manifesto

[Martin Steigerwald]

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