[Kde-pim] Problems with infrastructure

[Ben Cooksley]

Hi all,

Going to reply to all the various bits and pieces that have been
mentioned in order now. Apologies for the long mail.

For deleting branches, I think we can allow this - given some
protection for certain branches (like the KDE/* branches for
instance). Note that courtesy of the backup functionality in our
hooks, no branch or tag is ever truly deleted from a repository on
git.kde.org. I don't know how easy it would be to alter this behaviour
based on the account name of the developer.

In terms of tools: for both clear messaging, and to minimize
maintenance effort we need to have just a single tool. It isn't just
the tool itself which has to be maintained: we have commit hooks,
integration with other bits of infrastructure and so forth which also
needs to both be implemented and maintained. The more custom work we
have, the harder it is to upgrade things. We'll confuse newcomers if
projects A, B and C are reviewed on tool X while projects D, E and F
are reviewed on tool Y. A single tool would be best here. Let me make
clear that it is not a case of Reviewboard vs. Gerrit here - as other
options need to be evaluated too.

In regards to the difficulty of Gerrit - I tend to agree with this
argument (it took me at least a minute to find the comment button, and
I didn't even get to reviewing a diff). Plus there are major concerns
with integration into our infrastructure, such as pulling SSH keys
from LDAP for instance (no, you can't have the tool maintain them
itself - as mainline Git and Subversion need the keys too).

In terms of Reviewboard statistics - I don't have those to hand.
Someone would need to come up with some scripts which could be run
against the web server logs to generate some numbers here. We do have
the logs though.

Please note that any discussion of tools should be on the merits of
the tools themselves. Things like CI integration are addons, which
both Reviewboard and Gerrit are capable of. The only reason we don't
have Reviewboard integration yet is a combination of technical issues
(lack of SNI support in Java 6) and resource ones (some projects take
a long time to complete, and i'm concerned we don't have the
processing power).

In terms of a modern and consistent project tool - I agree here. A
long term todo item of sysadmin is to replace projects.kde.org. The
question is of course - with what. Chiliproject is now unmaintained,
so we do have to migrate off to another solution at some point. If the
new tool happens to be more integrated in terms of code review, that
is a bonus from my point of view (as it means the integration will be
better, and there is one less piece of infrastructure to maintain).

Thanks to Luca, we have a list of possible options to review. Contact
has already been made previously with the Gogs developers, so it is
possible they would be amenable to making changes necessary to support
what we need. Phabricator is also interesting, although we may have to
overcome some barriers with callsigns due to the sheer number of
repositories we have. It's code review tool is similar to Reviewboard,
but it has a much more sophisticated CLI client you can use. If anyone
has any other possible solutions, I would like to hear about them as
well.

@Jan: could you please outline what you consider to be the key
advantages? At the moment I understand that you are after:

1) CI integration to pre-validate the change before it gets reviewed
2) Ability to directly "git pull" the patch (which Phabricator's arc
tool would meet I believe?)

Thanks,
Ben