Changes to our Git infrastructure

[Ben Cooksley]

On Thu, Dec 25, 2014 at 10:47 PM, Jan Kundrát <jkt at kde.org> wrote:
> 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.

That is a weakness of our current anongit system - which needs to be
rebuilt anyway (it is running into scalability problems, but it has
served us well considering it has just had it's 4th birthday and has
run virtually unchanged since then)

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

Yes, they are active. They're active because scratch repositories are
intended for new work, which should comply with our guidelines on how
commits are made.
The audit hooks enforce this. Note that only people with sysadmin
powers - which includes yourself - have access to repo-management.

Not sure why random / 3rd party stuff would be imported - regardless
of whether it is a scratch repository or otherwise.
Distributions tend to frown upon bundling...

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

For new development projects. Usually people start something to
scratch their own itch and then that moves on to something which
others find useful to as well - and therefore contribute to also.
After a little while projects move to a mainline repository (these
usually have sufficient appeal to consider releasing and for
distributions to package).

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

This question was asked because some of the possible solutions out
there behave like Gitorious/Github and require a minimum level of
structure. If this was unacceptable then we'd need to exclude them
from the candidate shortlist.

Obviously it is rather pointless with our current Gitolite setup as it
is far too disruptive and work creating for everyone :)

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

We've never had any problems with immediate propagation once a
repository exists except when a mirror is having some trouble.
At least not to my knowledge anyway.

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

Thanks,
Ben