Development/Gerrit

    From KDE TechBase

    Geting Started

    Gerrit is a tool for web-based code review -- similar to ReviewBoard, but better in many ways.

    The first step is to active your account at Gerrit. Use your KDE Identity account to log in. Go into Settings -> SSH Keys and upload your public SSH key in there.

    Patches can be uploaded for review by any KDE user (users and developers alike). Here are a couple of one-time fixes to get you started. We will assume that your repository is already cloned from KDE (FIXME: do we want to prefer clones from Gerrit for some reason? I don't think so.)

     # At first, let's add a new git remote
     git remote add gerrit ssh://YourKdeIdentityUsername@gerrit.vesnicky.cesnet.cz:29418/RepositoryName
     # Gerrit needs a client-side hook for putting the Change-Id tags into commit messages
     scp -p -P 29418 YourKdeIdentityUsername@gerrit.vesnicky.cesnet.cz:hooks/commit-msg .git/hooks/
    

    Submitting Changes: Manual Setup

    There are a couple of options of how to use Gerrit from now on. The first one is to do everything by hand. Simply make commits and when you're done, push them to a "magic ref". Instead of doing stuff like git push gerrit master, you do:

     git push gerrit master:refs/for/master
    

    If you're working on a local feature branch, you can achieve a similar result by something like this:

     git push gerrit HEAD:refs/for/master
    

    The key point is the refs/for/ prefix. This is a magic ref, or a magic branch. It does not really exist, but whenever you push to it, Gerrit notices that you want to update or create a new patch/change/request/... and do the right thing.

    Gerrit will tell you what has happened -- either everything went well and then you got a link to a change request on the web, or something broke and then you should get an error message about what was it.

    Reviewing Changes

    See the guide at Gerrit's website for a basic tutorial. Any registered user can give a +1 .. -1 for Code Review. KDE developers can give +2 .. -2 for any review request. At least one +2 and zero -2s are needed for a change to be submittable.

    Modifying Changes

    Just amend/rebase/modify-in-any-other-way your commit and push to refs/for/targetBranchName. As long as the Change-Id line in the commit is preserved, Gerrit will do the right thing and notice that it's an updated version of an existing change.

    Nice Tweaks

    FIXME

    BoF at Akademy

    Someone suggested to use Frameworks Meeting (Room 1 - September 9th, afternoon).

    Also the PIM one (Room 4 - September 9th, morning)

    TODO list

    • Documentation: Write a howto for users/developers
    • Define how to get support
      • sysadmin's tickets?
        • gerrit admins have to be able to read these
      • Anything which needs hard-core stuff like recreating the whole VM: a sysadmin should file a ticket at CESNET's XIFI support. Any user who does that will be shot.
    • give access to additional admins
      • frederik gladhorn?
      • tosky?
      • ossi?
      • Who else? Register at Gerrit, send a mail to jkt and I'll make it happen.
    • take care of regular backups
      • PostgreSQL DB
      • git's refs/changes/*
    • Implement the CI
      • Jenkins, its job builder, zuul,...
      • Tool idea: run krazy over submitted patches before committing and inform committer about possible changes
    • Get SSH keys from LDAP (bugreport)