Killing the gerrit to dev-list spam ...

[Stephan Bergmann]

On 05/01/2013 09:33 PM, Bjoern Michaelsen wrote:
> Opinions?

My initial reaction to the gerrit web UI is "it sucks."  Take, e.g., 
comments made directly in the source code:  On a change's overview page, 
you can see that there /are/ comments to certain files of a patch set, 
but to actually see those comments, you need to click on the individual 
files (and if you happen to be logged into gerrit, the file you looked 
at is automatically marked as reviewed when you hit the browser's back 
button; scary, even if that is reportedly only a private marker only 
seen by yourself).  This does not make it easy at all to discover and 
contribute to a discussion.

One major rationale for the current dev-list spamming is so that people 
like me get informed about pending changes, to ensure changes are 
reviewed in a timely way.  Upon reflection, one could argue that people 
like me should adjust their working habits---instead of continually 
observing only the ML, we should also continually observe 
<https://gerrit.libreoffice.org/#/q/status:open,n,z>.  And switch the 
dev-list spamming off again.

But upon yet further reflection, it appears to me that mail does hit a 
sweet spot there.  Like with git commits, where in principle one can 
stay informed via git fetch/git log.  But, at least to me, it appears 
way more practical to instead do that via the automatically-fed commit 
ML:  My mail reader keeps track of which commits I did not yet look at. 
  I can flag commits as interesting to come back to them later when I 
have more time (though that typically means: never).  I can easily 
compose a reply mail to comment on a commit, and if I include the 
general ML in that mail, this can start a useful discussion.  In short, 
it is a format that makes it easy to consume the information and to 
contribute to it.  A counter-example is your average bug-tracker, which 
is not mail-based, but still can give you the feeling that you are on 
top of the information (and I think an important part there is that the 
bug-tracker makes all the information about a single bug immediately 
visible on a single web page).

None of that feels really true with gerrit, at least from my grumpy and 
skeptical position.  Sure, I should try to adjust my habits, become more 
comfortable with that gerrit web UI (or any sort of CLI).  But, to be 
honest, gerrit in its current form simply does not appear very usable to 
me.  And all the discussion whether and how to replicate information 
from gerrit (a tool intended to let people discover and contribute) in 
an ML (so people can actually discover and contribute) is testament to that.

Stephan