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 > [email protected] > https://mail.kde.org/mailman/listinfo/kde-community
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ kde-community mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-community
