Another proposal for modernization of our infrastructure
kevin.kofler at chello.at
Fri Jan 30 02:30:55 GMT 2015
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
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
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.
Another thing I'm a bit concerned about is the widespread reliance on
write in section 3.2.1:
> 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
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
* 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-
More information about the kde-core-devel