Another proposal for modernization of our infrastructure

[Martin Graesslin]

On Thursday 29 January 2015 12:25:57 Jan Kundrát wrote:
> On Wednesday, 28 January 2015 13:14:14 CEST, Martin Gräßlin wrote:
> > Navigation through the code is difficult, you cannot see the
> > complete change in one, but have to go through each file. This
> > is something I consider as unfortunate as normally I prefer reading the
> > changes to the header before the implementation, but due to alphabetic
> > ordering we do not have this. Unfortunately when navigating through
> > the change to get to the header file the implementation is marked as
> > "you have reviewed it".
> 
> Hi Martin, thanks for an excellent idea, sorting headers before actual code
> changes makes a lot of sense. I have a quick'n'dirty patch at [1].

I didn't want to imply that my workflow should be duckttaped - I don't claim 
that I have the perfect workflow and I only used the example of how the 
underlying problem is affecting my reviewing workflow.

> 
> Git has a config diff.orderfile option which might solve this reasonably
> well. Do you think that the following sorting order is reasonable for a
> KDE's default?
> 
> CMake*
> cmake*
> src/*.h
> src/*.cpp
> *test*/*.h
> *test*/*.cpp
> 
> > 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: "]" is a key which is great to use on an English layout but on
> > many other layouts it's just a very cumbersome to use key.
> 
> Do you have some suggestions on how this could be improved? Upstream is
> quite friendly, and I'll be happy to offer patches which improve the user
> experience.

I'm sorry but if I were able to improve UX, I would have enough to do on KDE 
software ;-)

Also I don't think it can be improved, this looks really fundamental in 
gerrit. I am not the only one who notices the problem and AFAIU Qt even 
patches around the issues. Given that I'm not confident that we can improve 
the software, that upstream accepts the changes and that upstream doesn't 
break the UI again in future releases.

Like Eike I consider this as very important as I spent quite some time each 
day creating review requests or reviewing other peoples code.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150130/d57bab61/attachment.sig>