[kde-community] Official KDE mirror on github

[Valentin Rusu]

* John Layt <jlayt at kde.org> [2015-08-18 20:10:25 +0100]:

> 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.

Right! Thanks for thinking at all these items. I think that's only the
tip of the iceberg. Lots of energy should go into this.  Wouldn't be
that energy better used to enhance KDE applications?

Now I'm wondering how could we avoid mirroring all the repos to Github.
And here's my idea: create a Github repo there, containing a tool able
to extract KDE sources from their actual location. The base could be
kdesrc-build preconfigured for Github fanatics, helping them to come to
our infrastructure. That thing should have the right amount of
documentation (I mean, not too much, but enough to get them started). In
the process, they'll discover Phabricator and eventually get hooked!

I think that may be way more simpler, wouldn't it?


-- 
Valentin Rusu
IRC: valir