Changes to our Git infrastructure

Jeff Mitchell mitchell at
Mon Dec 29 21:19:37 GMT 2014

On 29 Dec 2014, at 15:20, Thomas Friedrichsmeier wrote:
> 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.

Right -- so my suggestion is that we work to get rid of that shyness. 
That's a social issue. See below...

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

Exactly, so this is the root of the social issue. And for the current 
git hosting solution, this is correct. But for the next gen solution, it 
doesn't have to be.

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

Sure. So I think this is something that can be accommodated except for 
the you-do-it-yourselfness. And for what it's worth, it's possible that 
the do-it-yourselfness could still be accommodated but would require 
custom patching -- currently -- and that is something that we are 
somewhat loathe to do to the greatest extent possible. It has been the 
root of many a problem, especially in Bugzilla.

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

I'm honestly not sure how to answer that; scratch repos are very much an 
implementation because we had a solution. It seemed like something that 
could be useful, and we had the capability with the current software, so 
we did it. In hindsight, it has been problematic.


More information about the kde-core-devel mailing list