[Development] the need to add a Task-Number in the release branch ...
Lars.Knoll at digia.com
Thu Nov 14 14:18:51 CET 2013
On 14.11.13 13:50, "Oswald Buddenhagen" <oswald.buddenhagen at digia.com>
>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>
>> >or to put is a bit concisely, the proposal is to simply pay attention
>> >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.
>> >creating jira tasks just for the sake of being able to reference them
>> >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
More information about the Development