[kde-community] Official KDE mirror on github

John Layt jlayt at kde.org
Tue Aug 18 19:10:25 UTC 2015


So there seems to be some rough consensus here?

* That while not ideal, it is pragmatic to mirror our code on Github
as it could increase visibility and may help attract new developers or
at least new users for Frameworks.
* That we should do it in a co-ordinated, consistent, automated,
officially sanctioned way as part of our infrastructure before others
do it in an informal, inconsistent sub-standard way that might even
accidentally breach their manifesto undertakings.
* That it should be a one-way mirror by default, with issues and pull
requests disabled.
* That individual apps can choose to 'accept' pull requests via
Github, but any patches have to be applied through the normal KDE
infrastructure(using a standard documented method?).
* That individual apps can choose to opt out entirely.
* That all repos mirrored must have a standard README.md file that
states the correct procedure for submitting bugs and patches.
* That we probably shouldn't 'bless' Github as the only place we
mirror our code but could mirror more widely

So, is there a volunteer to project manage this? I can see a lot of
background work needs doing first to design a workflow and check
everything will actually work automatically. They will need to talk
with the sysadmins and research how Github/Gitlab/Bitbucket/whatever
works, then come back here with a detailed proposal, then see it gets
implemented correctly.

Some points off the top of my head:
* How do other orgs like Gnome and Apace do this?
* Given the size of our code base, do we need to talk to Github first
to see if that might cause issues, or if they can make the process
easier?
* What will our organisation name be?
* Do we want a single organisation for KDE Community with several
hundred repos directly under it, or separate orgs for the main
products, KDE Frameworks, KDE Plasma and KDE Applications (possibly
split into modules or apps?) Or is some kind of org hierarchy
possible?
* Who will the Org and App admins be on Github? Do we need dedicated
people, or just leave it to the official app maintainers if they can
be bothered? Or only require separate app level admins where they
opt-in to accepting pull requests?
* How do we link repos and orgs and their official KDE maintainers to
Github users to ensure the right people are managing the repos?
Standard SysAdmins ticket workflow?
* What repos do we want to mirror? Some may not be appropriate to have
mirrored, e.g www.
* Can we script the mirror creation process in a generic way?
* Can we automate the mirror creation and update process based on a
metadata flag for repos opting in/out and where does that flag live?
(useful to to allow a staged implementation or exclude repos like www)
* What repos do we want to trial this with, say the 5 most popular
Tier 1 Frameworks?
* How do we automatically turn off issues and merge requests?
* What is the preferred procedure for dealing with merge requests and
can this be scripted?
* What other sites to mirror to? Gitlab? Bitbucket? Which are big
enough to worry about? Do they have mirror-only features? Can issue
tracking and pull requests be easily disabled?
* What needs to go in the README.md?
* Should the README.md be specific for the mirror and only in that
mirror copy, or a single global file in the main repo?
* Can we script the README.md creation as part of the initial mirror
creation process?
* Can we generate the README.md from one of the repo metadata files?
If so which one, do we need extra metadata fields, and should there
also be an automatic update hook for when the metadata file is
changed?
* What happens when a repo already has a README.md?
* What git hooks will be needed and who will write them? Do generic
ones already exist for the chosen services?
* What new documentation do we need and who will write it?
* What PR do we need to do around this, in particular emphasising it
is merely a mirror and not a migration?

Phew :-) I'm sure there's a lot more besides.

John.



More information about the kde-community mailing list