Changes to our Git infrastructure
jkt at kde.org
Thu Dec 25 09:47:45 GMT 2014
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.
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
More information about the kde-core-devel