Sysadmin report on the modernization of our infrastructure

[Ben Cooksley]

On Thu, Jan 22, 2015 at 3:54 AM, Milian Wolff <mail at milianw.de> wrote:
> 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.

That is correct - we have to evaluate it first, and no migration would
be rushed through in a matter of days.
Things have to be planned for, prepared, tested and pre-flight
migrations run before the final production migration is done.

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

Thanks,
Ben