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