[Development] the need to add a Task-Number in the release branch ...
oswald.buddenhagen at digia.com
Wed Nov 13 13:38:37 CET 2013
thiago proposed that all changes pushed for release need to come with a
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,
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:
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".
More information about the Development