Another proposal for modernization of our infrastructure

[Jan Kundrát]

On Friday, 30 January 2015 03:30:55 CEST, Kevin Kofler wrote:
> 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.)

Um, it seems that I managed to confuse myself here -- this feature already 
exists and is active on our instance. A content merge is already enabled. 
I'm afraid I never needeed it yet, so I cannot comment on what sorts of 
conflicts it can solve, and what conflicts require a human action to fix.

Maybe someone already needed this and can provide more details?

> As a result, people who opt to disable JavaScript in their browser for 
> whatever reason (e.g., security) will have:

I agree with the sentiment in general, but at the same time, one could 
reasonably point out that Gerrit's choice of port 29184 for git-over-SSH 
might trip some corporate firewalls because it is not HTTP or HTTPS. Sure, 
disabling outbound traffic to "insecure ports" can "increase security of 
our corporation". It is up to everyone to evaluate whether that particular 
benefit is something worth the trouble for them.

In this context, I wonder what security benefits it brings when someone 
disables JavaScript for a trusted service where the entire set of JS code 
is free software.

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

Note that even if people disable JS, they are still be able to do any of 
the following as soon as they get a change number from e.g. the project 
mailing list or an IRC channel:

- pull changes from Gerrit for local testing,
- upload patches and create new changes or push updates to existing ones,
- record a result of their code review, including full voting and an 
eventual merge.

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

Yes, the technical options are assentially unlimited and someone /could/ 
write code doing just that. Maybe nobody sees a value in disabling JS to be 
compelling enough to commit their time. Or maybe people actually like JS 
and appreciate the feature set it brings.

One benefit of having the UI implemented in JS is that the APIs are 
*guaranteed* to offer enough functionality to be able to implement an 
alternative client as, say, an IDE plugin. If Gerrit was generating static 
web pages, it would be very easy to accidentally introduce features which 
just could not be implemented in other clients because the required APIs 
were not made public by accident.

These other clients exist today, btw. If a lack of support for JS-less 
browsers bothers you, may I suggest installing Gertty? It even has support 
for making patch review offline when on a plane, and bidirectionally synces 
stuff when you reconnect later.

Cheers,
Jan

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