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

[Knoll Lars]

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

>moin,
>
>in
>http://lists.qt-project.org/pipermail/development/2013-June/011610.html
>thiago proposed that all changes pushed for release need to come with a
>task-number footer.
>the proposal met moderate approval.
>little surprisingly, thiago seems to be the only person (i noticed) who
>is actually enforcing this rule. and causing a lot of unnecessary churn,
>imo.
>
>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 only purpose of the exercise is convincing the reviewers (and the
>release team who stages the change, and possibly also yourself) that the
>change actually does belong into the release branch.
>as this pertains only to the review/integration process, i think it's
>sufficient if all related activity is limited to the relevant tool:
>gerrit.
>
>so my counter-proposal is this:
>- you don't *need* to create a task just for the sake of it (of course
>  you should still do it if it really helps you).
>  as an alternative to actually creating and prioritizing a task, you
>  can do it as a thought exercise (and possibly mention your priority
>  estimate in the commit message).
>- you need to convince the reviewer that the change is necessary to
>  start with. you do that in the commit message.
>  obviously, you should be doing that *anyway*, but maybe put a bit more
>  emphasis on it in release times. and keep it later on. ;)
>- if the urgency of the change is not obvious to the reviewer, they'll
>  say that in a comment.
>  you may now need to amend the commit message (if some key information
>  is missing, e.g., that the change causes incompatibility).
>  other than that, the obvious recourse is doing the convincing in
>  followup comments. you may even write a comment pre-emptively.
>
>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.

Cheers,
Lars