Dear Tom,
In message 20131116013913.GN420@bill-the-cat you wrote:
Here is my key problem. I cannot even figure out what to do with this page. I cannot display it in a format I am used to, not can I process it in a way I'm used to. I'm totally lost with that.
Scroll down to patch set 1, click on unified and you get: https://u-boot-review.googlesource.com/#/c/1221/1/common/cmd_nvedit.c,unifie... and that's a "fancy" unified diff (tabs denoted, line numbers added, highlighting on the changes within a line). Some of that is pretty useful, but I would like to know if you can tweak that once logged in.
Well, some might find this cool, but for me it is utterly useless. I cannot do anything with this format. I started working in UNIX environments about 30 years ago, and what I need is a text file. I'm using nmh / exmh as MUA< so each message on the mailing list is a separate text file. This is what I need, as I can _work_ with the data, using standard tools.
I can grep for basic information (like for other patches that touch similar code), I can run the message through checkpatch or other scripts, I can check if it applies to the source tree. I can open it in an editor and use standard tools like ctags etc. to get additional nformation about the source context, related files, definitions in header files and all that.
With Gerrit, I can do none of this. I am dumbed and blindfolded and restricted to tactile senses.
Yes, I guess I can download the patch and process it then, and then switch tools again to type a comment in an unwieldy and unchangable environment.
Yes, gerrit provides search tools (see [1]) - but compare this against plain old grep and the rest of the text processing tools in Unix...
To me, gerrit appears to be the type of tool used in Big Organizations style of work - capable of organizing the work and enforcing adherence to certain procedures and processes for big teams of engineers. Gerrit describes itself as "web based code review and project management for Git based projects". I think this is correct.
Maybe I'm wrong, but my understanding was that we were not primarily interested in introducing better project management tools, but in reducing the work load on the maintainers, making our work more efficient.
I have to admit that I have zero practical experience with gerrit (meaning I have never used it as core tool in any real-life project, and did only very limited and very basic testing - and the learning curve apears to be long and arduous!), but from what I've seen so far I see feel that indeed helps to better organize the work, but at the cose of considerable restrictions to in the tooling and interfaces, resulting (at least for me) in lower efficiency.
I've tried to find discussions of using gerrit in Linux kernel development. I found little - see [2]. I find statements like "git needs an friendly UI, web based is the future." not exactly convincing. There were a number discussions at the last Linux Conference / ELCE about maintainers' efficiency and scaling problems with the always growing work load. There are so many really excellent engineers in the Linxu project - but apparently none of them uses (or talks about considering to use) gerrit. Is it just lack of information, or intuition, fear of changing the well-known processes - or do they have good reasons?
I see a lot of open questions here...
[1] https://review.openstack.org/Documentation/user-search.html [2] http://lkml.indiana.edu/hypermail/linux/kernel/1003.0/00687.html
Best regards,
Wolfgang Denk