Thanks for pointing this out, indeed. But as far as I understand it,
there are separate tracker issues for each backport PR anyway, correct?
So these could be put into relation here, too.
Yes, each backport PR has a separate issue in the backport tracker, and
the full PR URL is placed in the _description_ (not in a custom field).
Also, there is no "need review" status in the backport tracker.
Theoretically, the script could of course take these two differences
into account. If the PR is targeting a stable branch, it would change
the tracker status to "In progress" instead of "Need review" and put the
PR URL in the issue description instead of putting the PR number in the
PR ID custom field.
So, yes, under these conditions I agree.
But if you are suggesting to use the new PR ID custom field in the
backport tracker, I'd rather not, for the following reasons.
First, the backport issues are created by copying. This brings in a lot
of duplicated information from the master issue - especially the entire
description (which can be very long) and all attachments (if any). The
script that creates the backport issues wipes the description clean and
deletes any attachments. Later, when the backport PR is opened, its full
URL is placed in the description. This, in my view, is better than
having an empty description, which is what I presume we'd have if we
switched to the PR ID field (I have not checked if it's possible to
disable the description field).
Second, having the PR URL as the sole piece of information in the
description really puts "front and center" what is, in the huge majority
of cases, the only salient/relevant piece of information regarding the
backport. Occasionally backport issues have some additional
backporting-specific information attached to them in the form of
comments, and this works well.
Third, we have scripting that automates the process of creating the
backport tracker issues and backport PRs, as well as
updating/cross-linking the two. Someone (presumably me) would need to
modify the scripts to accommodate the new custom field, yet the
usefulness of the field for backporting is not clear.
Fourth, as far as I can tell, the Pull Request ID field only takes a
number (at least, I got "Pull request ID is not a number" when I tried
to put a URL in it). I find having the entire URL of the PR readily
available in the tracker issue highly convenient and I'm reluctant to
give up that convenience.
Nathan
