Last modified: 2014-02-12 23:40:06 UTC
Created attachment 11936 [details] Example lengthy patch In Gerrit patchsets, comments tend to fall into three categories: 1) the user uploading new patchsets, 2) jenkins verifying the patchset, 3) actual code review comments. This leads to quite a mind-boggling interface. For an example, see the attachment (as a code reviewer, only the highlighted comments would be of any interest). One solution maybe could be to, rather than have a new comment for each patchset, have the comments be separated into sections based on patchset.
Just for reference, the screenshot seems to stem from https://gerrit.wikimedia.org/r/#/c/27022 > as a code reviewer, only the highlighted comments would be of any > interest Why would code reviewing want ignore jenkins output? Why would code reviewing want ignore newer patch sets? > One solution maybe could be to [...] have the comments be separated > into sections based on patchset. Comments specific to a patch set are typically made right in the code (See for example patch set 7 of the referenced change). To me, comments visible on the change screen are typically high level comments that rather focus on the change itself than on a specific detail that's only relevant to a single patch set. Even if such comments were made when patch set 7 was current, the warnings to check against ConfirmEdit are still relevant when reviewing patch set 14. So when tying such comments to a patch set, they'd probably get lost. To me, it's a huge benefit to see all the high level comments in a complete timeline. While I do not have any concrete metrics for our gerrit instance, it seems to me that changes with more than a dozen patch sets and being actively worked on more than five months after opening the change are rather the exception.
(In reply to comment #1) > Just for reference, the screenshot seems to stem from > https://gerrit.wikimedia.org/r/#/c/27022 > > > as a code reviewer, only the highlighted comments would be of any > > interest > > Why would code reviewing want ignore jenkins output? > Why would code reviewing want ignore newer patch sets? It's not that you want to ignore them, it's that they're not comments and yet still mix in as comments. When I want to jump into a patchset and see what discussion is going on, I don't care if Jenkins couldn't merge patchset 6.
