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