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". _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
