Changes to our Git infrastructure

[Jeff Mitchell]

On 29 Dec 2014, at 14:00, Thomas Friedrichsmeier wrote:
>> Out of the 846 repos I currently count in scratch/, nearly all of
>> them haven't seen a commit in years. Meanwhile that's an extra 846
>> repos that have to be hosted, distributed to anongits, and backed up.
>> That's not just a lot; that's the largest piece of our Git hosting.
>> There are more scratch repos than normal repos. If clone repos were
>> excluded, scratch repos would actually be a majority of all repos --
>> and again, most of them haven't been touched in years. People
>> complain about propagation delay of repos to anongits -- syncing all
>> these totally outdated repos is a major reason.
>
> ok, I can see your point. But, personally, I was absolutely unaware of
> that problem, so far. And, while it's absolutely possible that I've
> simply missed the relevant discussions(*), I tend to think that I
> may not be the only one. In fact, at a cursory glance, I cannot even
> find any relevant words of caution on either
> - https://sysadmin.kde.org/services/code-repositories/ or
> - https://community.kde.org/Sysadmin/GitKdeOrgManual
> .
>
> So lets not abandon a very useful concept without giving some soft
> measures a try, first:

I just want to point out that scratch repos may be useful to some 
people, but are also the easiest repo type for anyone to host anywhere, 
including on their own local filesystem. The concept was a bit flawed 
from the beginning -- it turned our Git hosting into a generic 
repository hosting system, even if only for confirmed developers. Yes, 
it's nice to have remote backup, but you can also get this from many 
other providers, your own server, your own laptop, or more.

I'm not saying that it shouldn't be easy for developers to get 
repositories to play around with on KDE infrastructure. I'm just 
questioning the idea (as in my original email, which is not part of your 
quote) that actually asking a sysadmin for one is too onerous a burden, 
so onerous that such projects will simply immediately fail to thrive, 
instead of the developer simply waiting an extra X hours to be able to 
push up to a central hosted repo from the local system. Those that feel 
that this is just too high a price to pay could help reduce it by 
handling repo requests.

Scratch repos are also not just problematic in terms of all of the 
out-of-date repositories; they're very much a feature enabled by our 
current system (they were enabled because we could do it, so why not). 
If we want to move to a new system and the many other benefits it might 
provide, the kind of sandboxing that makes scratch a safe place for 
developers to create repos at will may be hard to provide without more 
of the types of unmaintainable patches and customizing that cause Ben to 
describe our system as being held together with glue and duct tape. (The 
current scratch area itself is already entirely custom-coded on top of 
Gitolite, and that means it must be maintained.)

--Jeff