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

[Oswald Buddenhagen]

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".