Using Gerrit for code review in KDE

[Jan Kundrát]

On Sunday, 7 September 2014 21:27:44 CEST, Eike Hein wrote:
> I'm curious however, what's the state of manifesto-compliance[1]
> for the Gerrit instance? Does KDE Sysadmin have admin access and
> the ability to get the data out if needed?

This is a very good question. Right now, only I (and other CESNET's 
staffers) have root access in there, the PostgreSQL DB is not being backed 
up automatically and the refs/changes/* is not being replicated to KDE's 
git for technical reasons [1]. This is, however, not a final state -- I 
simply had to show up something at Akademy :).

There's a page at the wiki [2] where I'm collecting various missing bits. 
Giving out both root SSH access and Gerrit admin access is already listed 
in there; some people (thanks Frederik) have already agreed to volunteer as 
Gerrit admins, and I'll be more than happy to give this role to other 
people with some Gerrit experience as well. Automatic backups to KDE's own 
machines are also definitely planned. Can someone help me with these? Are 
there volunteers to help manage this service? If so, please make yourselves 
known.

The VM itself runs on CESNET's/XIFI's OpenStack-based cloud. There's 
currently a small limitation with the version of Keystone which is used 
where apparently the administration can only happen through a shared 
OpenStack account (in OS's speach, there are just tenants, not groups of 
accounts). I'll be happy to share the respective credentials with KDE's 
sysadmins so that they're able to reboot the VM or do anything else with it 
in case it's needed. It's a pity that I cannot just point you to FI-WARE's 
cloud portal to register in there and ask for some credentials so that I 
could add you to some group...

The VM is installed and managed through Puppet. I'll be sharing the recipes 
once I get an approval at work (and this one will probably take some time).

Once everything described above is done, the worst case (in a very unlikely 
situation where CESNET has to discontinue this service on a short notice), 
it will be easy to migrate everything to any other cloud provider (and 
trivial if the other cloud provider happens to use OpenStack). Even if the 
impossible happened and CESNET decided to be actively hostile against KDE, 
the only thing which you would have to do would be:

a) launch a RHEL6-compatible machine somewhere and get it Puppetized,
b) apply the manifests,
c) restore from backup.

Again, thanks for asking this -- it's a very important question and I would 
hate to be a troublemaker here.

Cheers,
Jan

[1] Hooks would fire, which means that anybody who e.g. submits a change 
proposal with e.g. a CCMAIL: or BUG: keywords would be able to modify stuff 
even though they are no KDE developer. That's how the hooks at git.k.o work 
and changing this is not trivial -- the hooks coould be made to ignore the 
change based on the ref being pushed to, but then there's a problem because 
they hooks are also designed to ignore any commit which is already in 
another ref. This means that if, say, refs/changes/01/1/1 did not trigger a 
BUG: notification, once it's approved and get pushed to git.k.o's 
refs/heads/master, it *won't* fire again. Patches to hooks within 
sysadmin/repo-management.git are welcome, but Ben says these are a bit 
fragile.
[2] https://techbase.kde.org/Development/Gerrit#TODO_list

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/