Changes to our Git infrastructure

[Thiago Macieira]

For Gerrit:

> - Code Reviews:
>   - CLI client to make changes to the code review system and to manage
> the review (including retrieving the commits/patches)

Check. It's ssh host gerrit <subcommand>

>     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.

Check.

Also, from experience with Tizen's Gerrit: if the automatic list has more than 
3 people, all reviews stop getting done since everyone will be overwhelmed by 
reviews and they will thinki "it's someone else's problem on this one".

>   - Changes should be shown per-commit.

Check.

>   - Updates to reviews should leave prior reviews intact.

Check.

>   - Patches should be readable, commentable on line by line.

Check.

>   - Proposed changes are vetted by the CI system (compilability, tests,
> etc).

Check. The most common use is to run before merging into the official tree; Qt 
is the only project I know that does it after.

>  - Ability to accept the changes through the code review system

Check.

>   - Can mark a review as Bad (Don't Ship This) / Okay (Fine with it
> going in) / Good (Ship It)

Check. And you can change at will, add more categories, roles, etc.

>   - Can determine whether the review was by someone with commit rights.

Check. Not obvious, but it is doable, since you can look up people's group 
memberships. Might make a nicer feature to list the group(s) they're member of 
in the UI.

>   - Can produce a list of review requests given a certain set of
> criteria easily (preferrably savable)

Vague requirement without knowing what criteria were in mind here. So I'm 
going to go and say "check" since it can look up the criteria I want.

>   - Developers can tweak proposed changes easily before they are
> landed without the involvement of the submitter.

Check, you can push a new commit with the same Change-Id.

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

Check.

> - Project Management:
>   - Coherent and Performant

It's Java, but unlike Jenkins, we don't seem to have had problems with it for 
Qt.

>   - One canonical place to get the desired information (no more duplication)

Vague requirement.

> - Can either be links to elsewhere or directly hosted by the system 

Check.

> -
> Covers items like documentation (wiki, api), bug tracking, task boards, CI,
> code browsing and reviews, etc.

Vague. Assuming "items like documentation ..." are in Git, everything works.

> - Repository Hosting:
>   - Strong case has been made for retaining scratch repositories.

Out of scope, needs separate website and tools.

>   - A weaker case exists for clone repositories - making them more
> nice to have than critical.

Out of scope, needs separate website and tools.

Though it might be possible with the command-line, just not the web UI. I need 
to investigate.

>   - Anongit propagation should be within 1 minute.

Totally out of scope.

> - Overall: Sensible email notifications

Check, requires modifications from the Qt Project, since the default email 
notifications are not sensible.

> - Overall: Capable web APIs for the system as a whole

Check.

> 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.

Check. Dozens of projects use Gerrit.

> - 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.

Not check, since Gerrit alone will not correspond to KDE's desires (project 
creation, scratch clones, etc.)

> - 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.

Check.

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

I understand it is, but you'll have to speak to other sysadmins.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358