Changes to our Git infrastructure

[Jan Kundrát]

On Thursday, 25 December 2014 09:20:53 CEST, Ben Cooksley wrote:
> No comments on scratch

Scratch repositories ("I can do whatever here, it's simply mine") is good, 
but its actual utility is limited on current setup. If it takes 
minutes/half-an-hour for a new repo creation to propagate, I will just use 
GitHub because it gives me my repo right now.

Are the commit-sanity hooks ("audit hooks" in repo-management.git) active 
for scratch? If yes, they should IMHO be disabled because when I'm 
importing random, 3rd-party stuff in there, having to file a ticket or even 
making that commit myself in repo-management.git is too incovenient for me.

Which might be fine, maybe we don't want people to use KDE's git for these 
purposes. What's the purpose of scratch repos?

> or clone repositories?

These are IMHO useless. They got popular by GitHub because their workflow 
is built around pull requests and personal clones. My opinion is that this 
should be done by branches in a code review system, or at least by working 
in a branch(es) of the single repo. The target audience here are KDE 
developers, not everybody who can click a "Fork Me!" button.

> Or the movement of repositories?

Repo movement takes time of all involved people, and we're short on 
manpower. There could be good reasons for a move every now and then, but at 
the same time doing these moves routinely is something that I would like 
not to see.

In particular, I like the current repo structure by simply being "kio" and 
"trojita" instead of "kde/frameworks/kio" and "kde/extragear/pim/trojita". 
I will be OK with moving all KDE projects under a common prefix, e.g. 
"kde/kio" and "kde/trojita", making sure that everything sysadmin is 
"sysadmin/something" and perhaps even scratch stuff starting at 
"scratch/foo". That can really help set up proper ACLs with various tools 
(my favoriote one wouldn't care, though).

I don't think that encoding the "KDE module structure", such as 
"frameworks/foo" or "extragear/graphics/bar" would provide any value, and 
in fact, I would like to see the current mess of having essentially a flat 
list of git repos *and* a tree of them with different names being 
abolished. Why do we need that tree when it's not a real tree?

> Or how anongit functions (what you find works least well, etc)?

See above for issues with propagation delay. 30s is IMHO acceptable, half 
an hour not so much. Oh, and the same applies to force pushes (and 
especially to force pushes). If I need a shared repo, one of the use cases 
is that I'm using it to sync my work between two machines with no direct 
network path, and when I'm doing that, I'll be surely using force pushes 
because it might be my only way of testing. In a scratch repo, or in a 
personal branch of a shared repo.

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/