[TYPO3-core] Review system woes

[Alexander Opitz]

Hi Philipp,

> You should not write a test scenario in the commit message. You can find
> hinds on the internet on how to write a good commit message.

 >>>
commit a467d46876894f5d798a62a453ec384dbfbd3e4b
Author: Christian Kuhn <lolli at schwarzbu.ch>
Date:   Thu Feb 7 21:13:15 2013 +0100

     [BUGFIX][Cache] Method parameter CGL fixes

     Change-Id: Ie237c62fcd25d0f4ac2430983183756c7aebc633
     Resolves: #45257
     Releases: 6.1, 6.0
<<<
Good hint.

 >>>
commit d7b5d829e7d9a3a6699803e5c7ea308e6b2f55ca
Author: Christian Kuhn <lolli at schwarzbu.ch>
Date:   Sun Feb 3 12:13:25 2013 +0100

     [!!!][TASK] Get rid of loadTCA and simplify FE cache behavior

     The frontend rendering aims to not load the full TCA including
     columns settings to reduce rendering time for full cache pages.
...
<<<
Oh the issue tracker description, nothing realy informational beside the 
bug tracker.

So a short message is realy enough: See: 
http://hg.mozilla.org/mozilla-central

Oposite linux kernel: 
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=log
But they have no central bug/issue tracker, most of them are described 
merge requests of many small commits in different git repos.


> Basically, describe the problem in one or two sentences, then describe how
> you fix it.

Why? If that is needed, then it is part of the bug report. And how I 
fixed it? Mostly by change the code, sometimes by removing cache files 
that don't get regenerated if they should.

> The purpose of the commit message is that you can are able to figure out why
> a specific chunk of code has change.

Yeah, look in the linked bug report, if the short message don't tell you 
all. In the bug tracker you can add or edit extra descriptions. Also 
later on, after commiting a patch. You don't need to double that 
information.

> All information not relevant for this should go to the issue tracker or
> change review system.

What information isn't relevant? And when put it into review system and 
when to put it in the issue tracker?

> That is why the links to the issue tracker on change review are also part of
> the commit message.

Thats nothing I claimed, that helps to find the informations.


> Once a change is in the review system, make sure to always add a comment
> there if you add information to the issue system.

There the hell begins, so we get folloowing:

issue tracker               gerrit
A: Yeah info                A: Some more info added in issue tracker
B: See new info in gerrit   B: My new info
...

You need both to check the information, and the problem raises if you 
have multiple patches for different TYPO3 versions in gerrit.

> Otherwise it might not get noticed. Of course, it would be best if a
 > change in the issue system would trigger a comment automatically,
> but that needs someone to get his hands dirty.

So it needs more/better integration.
Look at https://bugzilla.mozilla.org/show_bug.cgi?id=454880 there you 
have the box "Attachments" choose "Show Obsolete" on the bottom of the 
box. Now you see all attachements (like the commited patches to gerrit) 
with their + and - reviews.


If you have two systems, you will split the people in two groups and 
you'll get half the power.


-- 
Viele Grüße
Alexander Opitz
Developer

T: +49 341 47842 15

++++++++++++++
Netresearch - Passion for eCommerce
++++++++++++++

Netresearch GmbH & Co. KG
Nonnenstraße 11d - 04229 Leipzig
http://www.netresearch.de

Registergericht: AG Leipzig HRA 15614
Komplementär: Netresearch Beteiligungs GmbH, AG Leipzig HRB 17018
Geschäftsführer: Michael Ablass