[Development] the need to add a Task-Number in the release branch ...

[Knoll Lars]

On 14.11.13 13:50, "Oswald Buddenhagen" <oswald.buddenhagen at digia.com>
wrote:

>On Thu, Nov 14, 2013 at 07:52:27AM +0000, Knoll Lars wrote:
>> On 13.11.13 13:38, "Oswald Buddenhagen" <oswald.buddenhagen at digia.com>
>>wrote:
>> >or to put is a bit concisely, the proposal is to simply pay attention
>>to
>> >the existing rules consistently instead of creating an entirely
>> >unnecessary "paper trail".
>> 
>> I agree with the proposal.
>
>> But if there¹s no associated JIRA task, the commit message has to be
>> clear and state why this change belongs into the release branch.
>> Comments in gerrit are not good enough, as they are hard to trace.
>> 
>this is exactly what this was supposed to preempt:

Huh? I was saying that I don’t think we need to create JIRA tasks.

The commit message should always be clear, but if there’s no associated
task, you probably need a bit of extra argumentation in there.

Cheers,
Lars

>
>> >creating jira tasks just for the sake of being able to reference them
>>in
>> >the commit messages does not improve the quality of the git history.
>> > [...]
>
>the point is that once the change is in, the historical context is
>irrelevant (the additional information doesn't answer why the change was
>done, it doesn't show how the code evolved, it doesn't show whom to ask
>about it, etc. - it's just noise). if the context needs to be determined
>for some weird reason, that is certainly process-oriented, and can be
>done much better with the tool we use for that: gerrit (just take the
>change-id from the commit and enter it into gerrit's search field. i
>regularly do that; it's a much faster and more reliable way to find out
>when and into which branch a commit originally went, than trying to
>reverse-engineer the git commit tree).
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development