Another proposal for modernization of our infrastructure

Thomas Lübking thomas.luebking at gmail.com
Thu Jan 29 16:22:45 GMT 2015


On Mittwoch, 28. Januar 2015 13:14:14 CET, Martin Gräßlin wrote:

Ah. Web UI concerns.
Yes. Share most of them.

> Navigation through the code is difficult, you cannot see the 
> complete change in one, but have to go through each file.

+1

Ideally one could have show the patch at once (for small ones across some 
files) or file-by-file (RB sometimes gets really slow on showing HUUUUGE 
patches, like sed'ing a symbol name etc.)

Maybe it's possible to borrow or upstream the Qt mod?

> What I also find bad is that you actually need to know the
> "magic" keyboard shortcuts to use it in a sane way.
> And the shortcuts are to be honest strange

Kids. =)
Those actually look a lot like vi (not vim) shortcuts.
But yes: to everybody not familiar w/ vi those are ... suboptimal (and i 
recall my thoughts on vi when being confronted with it for the first time)

@Jan
If the shortcuts can be freely chosen, one might want to make use of the 
modern inventions to keyboards like the page up/down or arrow keys (along a 
modifier, eg. ctrl)

?: Open shortcut help
Alt + PgUp / PgDown: 	Previous comment / Next comment (kate bookmarks)
<Ctrl> + f:		Search (as present)
F3 / Shift + F3: 	Next diff chunk or search result / Previous diff chunk
j / k :		Next line / Previous line (ok, because arrow up/down work as well)
Right/Left Arrow:	Expand or collapse comment (treeview style)
Shift + Right/Left Arrow: Expand or collapse all comments on current line
Alt+ Left/Right:	Previous/Next file (typical browser history shortcut)

I've no good or strong idea on:

<Shift> + m	:	Mark patch as reviewed and go to next unreviewed patch
seems ok.

,:		Show diff preferences
hardly ever used

i:		Toggle intraline difference
hardly ever used

a:		Reply and score
I've never sued that.

---------------------


> I do not like the comment threading of review board, but I consider gerrit 
> even worse.
What I like better on gerrit is that it doesn't spam the entire thread via 
mail (TOP QUOTING!!!!! ;-)

> All comments are collapsed and you have to go to 
> the diff to read the comments on the code.
+1
If any possible there should *really* be a brief context on the comment 
(ie. the code line reproduced)

> There is no threading at all involved. On review 
> board we quite often have threaded discussions, but I cannot see how this 
> could happen in gerrit.
When you click reply, you create a quote, but that's hardly optimal.

Also see https://groups.google.com/forum/m/#!topic/repo-discuss/VZuOTLzlDZ8 
on the specific matter and/or here http://benpfaff.org/writings/gerrit.html 
for a more extensive list on improvable things.

> into git doesn't change much. Whether I do:
> git push something magic:something other magic
> or
> rbt post -o --parent=somethingmagic

I'll disagree here and point my 50 commits review disaster (i canceled it 
immediately)

git push something magic:something other magic
    is actually just a variant of the canonical form (example)
git push origin master:master

Shortcutting "git push" can cause you trouble unless you operate on one 
repo + branch only, so one should know the full form and then there's no 
magic left.

Cheers,
Thomas




More information about the kde-core-devel mailing list