Enzyme -- some comments / suggestions

[Alexander van Loon]

Regarding (2), I was having trouble with the same commit, the one with the description ‘Actually activate the critical 
battery timer’, just a while ago. That commit insisted on not being saved. Finally when I persisted, after having reviewed all 
other commits (I only got to see commits to SVN somehow, nothing from Git) up to today, that commit was the last one 
left. Trying to save that one commit first resulted in ‘Save unsuccesful’, but after trying some more it finally gave up it’s 
resistance and it saved. I’ve seen this occur before with other commits and I hope it could be solved as well, it’s quite 
annoying.

I hope to see (3) implemented too, certainly now that almost everything has switched to Git. Totally agree with (5), 
because my eyes have to move more it slows my work down. It’s good that you mention (6), I’ve also had a lot of problems 
with not being able to correct mistakes in reviewing commits.

On Saturday 29 January 2011 02:36:12 Marco Krohn wrote:
> Dear all,
> 
> It is quite amazing to see how much the team has achieved so
> far--great job everyone! Also thanks a lot for all your great work on
> the Enzyme platform, Danny. It is so much more complete and usable
> than its initial version. My recent contribution was some review work:
> in the last few days I looked at around 1500 commits and will continue
> to do so! We are now about 12 days behind and I hope we are in
> "real-time" mode soon again--some helping hands are welcome!!!
> 
> 
> Some things that I have noticed while being in "reviewing spree":
> 
> (1) Strings in commit messages like "Bug 210131" are not parsed
> 
> (2) Saving commits does not work correctly. I have attached three
> screenshots showing what is happening:
>   (i) before selecting anything
>   (ii) after selecting the first commit message (1214662) for inclusion
>   (iii) after pressing save (in the menu bar the message "1 commit
> saved" appears).
> Result: the first commit message 1214662 is _not_ saved; the second
> commit message (1215120) was removed from the list
> 
> (3) "commit path sorting": I am not sure how to use this to sort git
> commits, e.g., what is the correct entry to categorize the following
> commit under "kdemultimedia"?
> 
> Commit 6b12b41... by Sergey Ivanov (ivanov)
> [Amarok] /
> 
> (4) Is commit path sorting case sensitive? For example, there are
> currently two entries: (a) "KDevelop/", (b) "/kdevelop/"
> If a regex like approach is possible we could certainly delete one version
> 
> (5) When reviewing messages my eyes are fixed on the left side of the
> screen in order to read the comment and the affected file / path. The
> "broken box" icon (for a bug) is the only information which is on the
> right hand side of the screen (e.g. see the first screenshot). May I
> suggest to move the "broken box" icon to the left hand side of the
> screen?
> 
> (6) Changing previously "selected" to "deselected" is not possible.
> For example, select the first entry and deselect the second one. Then
> going back (I am using the mouse) to the first one and click on
> "deselect" does not work. Instead the third entry becomes deselected.
> Btw: the other way around, i.e., changing a deselected entry to a
> selected one works as expected.
> 
> (7) When I found that something was going wrong (like in (6)) I
> intuitively looked for a "cancel" button. May I suggest to add next to
> the "save"  button a "cancel" button (which is basically just a link
> to "review")
> 
> (8) Regarding the git commit id link: linking to projects.kde.org
> would be great. However, I am not sure whether the path information
> e.g. "calligra/repository" is easily available:
> 
> https://projects.kde.org/projects/calligra/repository/revisions/e5646ba8322e925c16920a5fa198f22bdb812bb5
> 
> By the way: https://projects.kde.org/projects/ gives a nice overview
> of the various KDE git projects.
> 
> (9)  I think we had the question in the past: what happens if two
> people reviewing commit messages. I found out the hard way after going
> through 100 commit messages... someone was a bit faster than me and my
> work was lost ;-) At this point I stopped reviewing because I was
> afraid to "lose" another round against mutlu :-) On the positive side:
> it seems there was no data corruption!
> 
> While sorting messages by date makes generally sense I wished some
> randomization would have saved some of my work. I do not know whether
> there is an easy solution. If user gets a randomized sample of the
> commit messages for the next 5 days this would certainly be helpful to
> avoid duplication of effort.
> 
> 
> Have a great weekend everyone,
>   Marco