Changes to our Git infrastructure

[Thomas Friedrichsmeier]

Hi,

On Mon, 29 Dec 2014 14:41:03 -0500
"Jeff Mitchell" <mitchell at kde.org> wrote:
> 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.

well, in many but not all cases, this may be true. Here's my example
use case: I am currently considering hosting an "i18n supplement" in a
scratch repo. The idea would be to make it easy for developers or
build-systems to clone translations from this. Not quite sure the idea
will fly, so I'm shy to request a "real" repo for this. But also, a
local repo would be pointless, and using a separate provider would feel
wrong. Branching is equally out of question, as this is separate data.
 
> 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.

No, having to ask a sysadmin is not necessarily a show-stopper to me.
But it certainly does create the aura of "don't do this unless you are
sure you know what you are doing". Also note that currently the wording
on the wiki is:

"Note that we have deliberately decided not to allow the direct
creation of KDE Playground projects; the path to existence for a KDE
Playground repository project always leads through a personal scratch
space first. This is to give you the power to decide whether your
project is ready, and also to force you to deliberate whether it truly
is."

Well, that could be changed. And the psychological barrier could
further be lowered by providing a dedicated web form, for instance.
Note that I'm not really attached to the exact process of creating a
scratch repo. But the _concept_ of being able to create a repo
- without _any_ questions asked (other than the name)
- in a not-quite-as-visible area / prefix
- following more liberal rules, e.g. about force pushing
seems important to me.

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

I am absolutely not qualified to comment on the pain this is causing to
you sysadmins. But are we talking about / is the problem inherent to the
_concept_ of scratch repos, or is it a problem of the implementation of
how exactly scratch repos are created?

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20141229/1ca3eb2d/attachment.sig>