Changes to our Git infrastructure

[Jeff Mitchell]

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.

--Jeff