Sysadmin report on the modernization of our infrastructure

[Jan Kundrát]

Hi Ben,
thanks for your proposal. A couple of points which I'm missing from the 
text, and a few further questions as well:

1) A detailed list of the issues which a competing proposal would have to 
address. Some glimpse of this is in the last paragraph, but that's just a 
very high-level description. Could you please provide a list of 
functionality that has to be supported by a replacement, so that we can 
work out how to get there?

2) It is unclear to me whether you plan to use Gitolite in future or not. 
At first, the proposal says that there are inherent scaling issues with it 
and that the replication is beyond its scaling limits, yet at the end of 
the document you say that a replacement has to support Gitolite metadata 
generation. I do not understand that.

3) The idea of rolling out Phabricator is not specified, so it's hard to 
get a proper understanding of what exactly will have to be done. What 
changes in workflow are going to be needed? What custom tooling will have 
to be written? How is Phabricator going to play with the rest of the 
infrastructure? What pieces of the infrastructure will actually remain?

4) You have indicated some (pretty important to me) limitations of 
Phabricator with a remark that "it's a fast moving software, we might get 
there eventually". I think that SW should be evaluated based on 
functionality present right now in the development version and not based on 
opened feature requests. We've been promising e.g. support for multiple 
accounts in Trojita for many years already, and it didn't make it happen.

5) You're indicating a requirement for scratch repos to be present from the 
very beginning, yet you acknowledge that Phabricator won't have it for at 
least six months.

6) The discussion focuses in highlighting Phabricator's benefits, which is 
understandable from your point of view. However, much of the same things 
can be said about Gerrit as well, especially its backing by a well-known 
player, adoption by multiple companies and multinational corporations 
(SonyErisccon, SAP, KitWare,...) as well as by many FLOSS projects (Qt, 
Andorid, LibreOffice, Eclipse, OpenStack, WikiMedia, Typo3, Cyanogenmod, 
Tizen, and a ton of others). Its scaleability has also been verified by 
real-world use over many years (for far longer than Phabricator).

Now coming to Gerrit and its analyzis:

7) It is possible to have scratch repositories with Gerrit, but it's true 
that it will require a simple tool which verifies user's request and 
executes an API call with proper credentials. We're speaking about one 
trivial webapp or a shell script here.

8) There is no need for any modifications to Gerrit as your text implies. 
What is running and integrated into KDE right now is an unpatched release 
straight from upstream, with no custom plugins.

9) I do not know what effort for integration with KDE Indentity you're 
referring to. It's a simple LDAP server, and the entire "integration" was 
trivial. It's really just a matter of configuring Gerrit to talk to LDAP, 
which I expect to be also the case with Phabricator.

10) Re Phabricator's support for submitting and retrieving changes via pure 
git, I believe you're overly optimistic in this regard. This is a pretty 
fundamental design decision which can only be retroactively fitted with 
asignificant amount of pain.

11) While the Gerrit trial has been running for a few months, being used by 
real KDE projects and generated actual feedback and tweaks, there's been no 
trial of Phabricator so far. In my opinion, it is premature to have a plan 
for migration to a particular tool prior to having verified said tool in 
production environment. In this regard, your proposal effectively discusses 
throwing away the results we got with Gerrit, and fails to provide some 
rationale for that. Indeed, the question is "where is Phabricator better 
than Gerrit", and I propose to focus on this aspect in future.

12) WikiMedia uses Phabricator for issue tracking and nothing else -- it's 
just a Bugzilla replacement for them. According to publicly available 
information, their reasons for choosing Phabricator had everything to do 
with the PHP as a language known to all of their developers. They still use 
Gerrit for git repo management and code review.

So given that we're about to rebuild the whole Git infrastructure anyway, 
the counter-proposal is to build it around Gerrit this time. Based on what 
I know about KDE's infrastructure, Gerrit can fill in these roles without 
any problem. I would like to work with you towards that goal; are you 
interested?

Finally, I would like to say that I appreciate the work of the sysadmin 
team. In future though, I'd love to see a bit more transparency of the 
entire process. Right now it isn't clear to me whether investing a few 
additional man-months of my time towards working with Gerrit has any merit, 
or whether it's been already decided that the KDE's future is with 
Phabricator. I don't know who will make the final decision -- is it going 
to be Ben and Jeff, or are the contestants going to be judged by the wider 
community and how and using what criteria?

The way I see it, both Ben and Jeff (was the report written by anyone 
else?) have expressed their intention to go with Phabricator despite my 
long-standing and thorough work on evaluating Gerrit, and I'm a bit 
disappointed by that. It would be fine to reject Gerrit on technical 
rounds, but I haven't seen much of technical arguments here. So let's make 
this simple -- is this going to be a decision of the sysadmin team, or is 
there an actual potential of offering alternatives?

With kind regards,
Jan

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