Sysadmin report on the modernization of our infrastructure

[Milian Wolff]

On Wednesday 21 January 2015 11:44:00 Jan Kundrát wrote:
> 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?

Yes, a simple bullet point list would be useful. I'll list some stuff below 
also.

> 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.

Agreed.

> 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?

<snip>

> 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.

Agreed.

> 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).

Imo, quite the contrary. It concentrates on the issues the admins have with 
their current setup, and then shows how Phabricator could help with that. 

> Now coming to Gerrit and its analyzis:

<snip>

> 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.

I don't see where this is mentioned in regard to Gerrit. I can only find LDAP 
being mentioned when talking about the status quo for KDE, which does not 
include Gerrit.

> 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.

This belongs to the point below, imo. Or what are you referring to? If you do 
mean the git integration, then yes, maybe it's important to you, but it's 
really not important in the big picture, imo. And do note, I'd personally also 
prefer gerrit for reviewing.

> 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.

As far as I understand it, we (KDE) won't jump to Phabricator in a matter of 
days, rather it will take a few more months before we even start (correct?). 
There are still some other blockers upstream, which will be resolved. Lets see 
how this works out. Generally, I don't think its impossible to add this to 
Phabricator. So lets not be overly pessimistic, nor optimistic. Maybe this 
feature is added, maybe not. While I personally would also love to have it, 
it's a minor detail compared to the rest of the feature set, imo.

<snip>

> 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.

See http://www.mediawiki.org/wiki/Phabricator, what Jan says is true. But 
WikiMedia is in the process of migrating away from Gerrit, so what Ben says is 
also kinda true ;-)

Now to the following:

> 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.
> 
> 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.
>
> 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?

To my knowledge, here are some things that Gerrit does not provide, but 
Phabricator potentially provides:

- a project overview with a code browser, project meta data etc. pp. and a 
list of commits inside a repository. Qt still uses gitorious for this, afaik
- the ability to get notified about new commits in a project. (this is 
different from new reviews)
- Apparently the anongit problem, but Ben would need to fill in more details 
here.

then, there are some other things that are really nice to have in Phabricator, 
which are not available in Gerrit. But, imo, they are not as important as the 
above:

- post-commit review
- project management, todo / kanban board
- issue tracker (only if we ever port the bugzilla content over)
- paste (only if that would replace paste.kde.org)
- wiki (only if that could be used to replace the existing wiki structure)
- various tools which would help with release management, e.g. calendars / 
countdown timers / release branches
- overall, the app framework phabricator provides seems to indicate that its 
easy to extend, contrary to what I heard from gerrit

Please correct me if I'm wrong. I only know Gerrit from its usage in Qt.

Bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de