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

[Alan Alpert]

On Wed, Nov 13, 2013 at 4:38 AM, 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".

The "paper trail" is necessary for history and for communicating with
others and what I'm seeing here is that you want to be able to have it
entirely in gerrit (you haven't asked for any relevant "content" to be
dropped, just moved to review comments). Gerrit is the wrong tool for
that, review comments are not easily searchable. Even git is not
always that great, especially since we tell people that JIRA is where
we track issues and so that's the first place people will look. I'm
fine with the enhanced scrutiny on release branch when theoretically
*all* commits should have a JIRA task associated (even though everyone
agrees that it's not worth bothering with that for most work).

My only problem is that resubmitting the patches can be a problem
(needs to be at a workstation set up for development, then needs to be
re-approved). I'd recommend (and have kind of been doing) that it's
okay to just add the JIRA task number as a comment on gerrit. Then you
don't get the automatic JIRA source integration, but it's easy enough
to put in a comment with the link to the codereview change (mitigating
the 'searchable' problem) or filling out the changes field yourself
(ah, that takes me back ;) ).

--
Alan Alpert