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/
