[kde-community] Official KDE mirror on github

[Martin Graesslin]

On Tuesday, August 18, 2015 08:10:25 PM John Layt wrote:
> So there seems to be some rough consensus here?

thanks for the great summary mail!

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

Count me in, though I don't want to spearhead the effort.

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

Maybe we could start with a Kanboard on our new Phabricator instance and put 
those tasks there ;-)

Cheers
Martin

> 
> John.
> _______________________________________________
> kde-community mailing list
> kde-community at kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20150819/c74c397d/attachment.sig>