Changes to our Git infrastructure
jkt at kde.org
Thu Dec 25 11:01:20 GMT 2014
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
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.
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
More information about the kde-core-devel