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/
