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
