Changes to our Git infrastructure

[Ben Cooksley]

Hi all,

I've gone over the comments everyone has made thus far and came up
with the following community wishlist as it were.
It represents a combination of what everyone has said, in a fairly
distilled form.

Regrettably there were one or two items which conflicted. I sided with
the option which kept the barrier to entry as low
as possible as that seemed to be the greater consensus within the thread.

- Code Reviews:
  - CLI client to make changes to the code review system and to manage
the review (including retrieving the commits/patches)
    Client should have good documentation.
  - System should automatically set the CC / Reviewers / etc for a
review rather than the submitter needing to know who to set.
  - Changes should be shown per-commit.
  - Updates to reviews should leave prior reviews intact.
  - Patches should be readable, commentable on line by line.
  - Proposed changes are vetted by the CI system (compilability, tests, etc).
  - Ability to accept the changes through the code review system
  - Can mark a review as Bad (Don't Ship This) / Okay (Fine with it
going in) / Good (Ship It)
  - Can determine whether the review was by someone with commit rights.
  - Can produce a list of review requests given a certain set of
criteria easily (preferrably savable)
  - Developers can tweak proposed changes easily before they are
landed without the involvement of the submitter.

- Post Commit Review:
  - Be able to comment on reviews, other than by replying to a mail on
kde-commits

- Project Management:
  - Coherent and Performant
  - One canonical place to get the desired information (no more duplication)
  - Can either be links to elsewhere or directly hosted by the system
  - Covers items like documentation (wiki, api), bug tracking, task
boards, CI, code browsing and reviews, etc.

- Repository Hosting:
  - Strong case has been made for retaining scratch repositories.
  - A weaker case exists for clone repositories - making them more
nice to have than critical.
  - Anongit propagation should be within 1 minute.

- Overall: Sensible email notifications
- Overall: Capable web APIs for the system as a whole

There are also a couple of items which come from sysadmin, to make
things easier for us in the long run:

- Supported well:
  Upstream should be stable with a viable future.
  We should also be able to build a relationship with one or more
developers who authored/maintain the application.
  This is helpful in obtaining assistance should it be necessary and
assists us in getting additions upstreamed.

- Integrated:
  A single application which handles everything will always be able to
offer a better and more coherent experience than several applications
we have connected to each other.
  There is also a lower maintenance burden from an integrated
application, as it is one piece of software to update - not 3 or 4.

- Care about compatibility:
  Upstream should have an interest in stable interfaces, both
externally facing (Web APIs) and internal (application plugins, etc)
  As the recent Dr Konqi problems have demonstrated, upstreams which
act without regard for backwards compatibility can introduce
significant problems for us.

- Scalable:
  The applications which make up our infrastructure need to be able to
handle the demands we place on them without consuming resources
unnecessarily.

Commentary on the above would be appreciated.

As this is quite an extensive list of requirements, we won't be able
to get everyone what they're after. We'll have to do things on a best
effort basis - depending on what is available, what features are
missing, etc. Unfortunately there is no perfect solution here - it
just does not exist.

Thanks,
Ben