Another proposal for modernization of our infrastructure

[Kevin Kofler]

Hi,

Jan Kundrát wrote:
> Feedback is very welcome.

First of all, I would like to apologize for my overly negative tone in your 
prior feedback threads.

I would also like to point out that I have absolutely no experience with 
Phabricator (the solution proposed by the competing proposal), and as such, 
I cannot really compare the 2 proposals nor give a personal preference.


There are 2 points in your (Gerrit-based) proposal that I would like to 
comment on:


1. File-level conflict resolution

> 3.2.2 Conflicting Changes
> When a project is big enough, sooner or later there will be patches laying
> around which are mutually incompatible. By default, Gerrit uses merge
> algorithm that solves conflicts on a file level. A list of changes which
> modify the same files is shown within the UI. Changes which cannot be
> submitted due to a merge failure are clearly marked as needing a rebase in
> all UIs. That way, a developer can make sure that a conflict is solved in
> a meaningful way and without introducing bugs.

Unfortunately, file level strikes me as a less than helpful default. Can 
this be changed to line-level merges in our instance? (I think the ideal 
would be to use git's native merging algorithm(s), but I expect some 
limitations due to the convenient web resolving UI.)

In community-developed Free Software projects (also known as the Open Source 
Development Model or the "bazaar" model), very often, reviews modify files 
that have also been touched by other people before the review is processed, 
or an uploaded patch was generated against a release tarball and the file 
has since changed in master. I fear that having to manually merge as soon as 
there is a "conflict" at the level of the entire file is going to be really 
painful.

This is different from some of the existing large-scale deployments (e.g., 
OpenStack), which, even where the end product is Free, are largely company-
driven. I guess concurrent modification of a single file by different people 
is not so common in such corporate ("cathedral") development models, which 
explains the default.


2. Reliance on client-side JavaScript

Another thing I'm a bit concerned about is the widespread reliance on 
client-side JavaScript in both your proposal and upstream Gerrit. As you 
write in section 3.2.1:
> The bundled web UIs are implemented as a client-side JavaScript
> application that talk to Gerrit via the REST APIs. There is no artificial
> feature gap between what can be done with official tools and what is
> available to other UIs. Alternative web UIs using various modern web
> frameworks are under development.

In addition, your existing and proposed code for integrating independent 
services between each other (section 4.1, and section 3.2.11 for the special 
case of Bugzilla) is (or will be) also written in client-side JavaScript.

As a result, people who opt to disable JavaScript in their browser for 
whatever reason (e.g., security) will have:
* the Gerrit web interface not working at all (or at least not until such an
  "alternative web UI" is implemented in a way not requiring client-side
  JavaScript and deployed on KDE infrastructure),
* the integration between various utilities also not working, e.g., Bugzilla
  will not list pending review requests at all.
To me, this contradicts the web maxim of "graceful degradation".

Why can the work not be done on the server side? Especially for the 
integration between services, I would expect a simple API call for data 
lookup to be doable on the server side at least as easily as from client-
side JavaScript.

        Kevin Kofler