Changes to our Git infrastructure

[Jan Kundrát]

On Thursday, 25 December 2014 11:06:05 CEST, Ben Cooksley wrote:
> Not sure why random / 3rd party stuff would be imported - regardless
> of whether it is a scratch repository or otherwise.
> Distributions tend to frown upon bundling...

I've had a need for this twice.

The first instance was trying to fix breakage in Ragel, a 3rd party SW 
which generates parsers. It contained logic error related to cross 
compilation. I wanted a place to host my modifications, and because I run 
into that problem during my work on KDE, I wanted to use KDE's infra for 
that. I couldn't, because I wasn't able to import upstream's content into 
my personal scratch repo.

The second case was a tool I wanted to use during my work on CI. It's not a 
SW library to be used by program we develop, but rather an existing tool 
which I wanted to extend with some additional level of functionality. 
Again, I wasn't able to import this due to the checking hooks, so I ended 
up using another hosting service.

>> Which might be fine, maybe we don't want people to use KDE's git for these
>> purposes. What's the purpose of scratch repos?
>
> For new development projects.

That makes sense. If the scratch repos are not for hosting "random crap I 
need for my KDE work", but rather "new stuff I create for KDE", then having 
these hooks operating in this strict mode is OK. In that case the message 
about the purpose of the scratch space should probably be made a bit 
stronger, because I wasn't aware of this limitation despite being with KDE 
since 2007.

I'm not saying that limiting the intended use cases like this is 
necessarily bad. There's always Gitorious, GitHub, repo.or.cz and other 
similar services. If we don't want to be in the business of providing KDE 
developers a universal Git hosting, we don't have to be. There's a 
downside, though, that people who already "have to use something non-KDE" 
might want to default to using these permissive, 3rd-party hosting services 
even for projects that "should be on git.k.o", simply because the other 
platform has worked well all the time before.

> This question was asked because some of the possible solutions out
> there behave like Gitorious/Github and require a minimum level of
> structure. If this was unacceptable then we'd need to exclude them
> from the candidate shortlist.

Ah, OK. I think it would be a bit short-sighted to eliminate a potentially 
more useful tool only on the basis of having a one-time config change. (My 
personal favorite doesn't require such a change.)

> We've never had any problems with immediate propagation once a
> repository exists except when a mirror is having some trouble.
> At least not to my knowledge anyway.

I've seen repeated problems with propagation delay of *force* pushes to 
git at git.kde.org:clones/websites/build-kde-org/jkt/th-build.git . I think I 
mentioned them on IRC already.

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/