Changes to our Git infrastructure

[Alex Merry]

On Wednesday 24 December 2014 00:20:18 Ben Cooksley wrote:
> Hi all,
> 
> As has been made evident in the prior thread there are quite a few
> interesting ideas floating around about what our Git infrastructure
> should be capable of.
> 
> Our current one was constructed when KDE first seriously migrated to
> Git following the Gitorious experiments, and it shows. (As a sysadmin
> I can attest that parts of it are held together by digital glue and
> tape).
> 
> Before we go ahead and jump to a new platform though - we need to know
> what we want.
> Can everyone please suggest what they think are the things they'd like
> to see feature wise?

While I think Milian's idea of a command-line-managed system is useful and 
efficient, I think discoverability (or "remindability") is important. Too many 
developers work with too many different systems to necessarily always have the 
specific commands on hand. Whether it's a tool that you can pass --help to or a 
web page you can finish things up on, I'd like a way to not have to remember 
too many arcane commands (even git has pretty comprehensive man pages).

I would also like as much information to be inferred as is reasonable (eg: I 
shouldn't have to say who I am and what repo I am working on every time, 
because that should be stored somewhere/inferred from the repository, and this 
should work with kde:foo.git and anongit.kde.org and git.kde.org remotes).

A good patch review system is essential - I'm not as fussed as Milian about 
"all on one page" reviews, but syntax highlighting, line- and block-
annotations and global comments are all essential, and some sort of "don't 
ship", "fine by me", "ship it" system would be nice. The possibility of multi-
commit reviews would be great, but I could live with them being compressed 
into a single diff.

I'd also like to see a coherent (and *fast*) project management system - 
ideally, one canonical place to find projects and find all the information about 
a paricular project (although I realise that's a big ask) - description, 
online git browsing, maintainer info, wiki, documentation, etc. Even if some 
of those are links - but they should be auto-generated links as far as 
possible, or come from information in the repo itself (eg: see the 
framework.yaml files in the Frameworks repos).

Alex