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
