Thanks! So even for backports there is a 1:1 relationship between
tracker issues and their corresponding pull requests that could be
captured with this custom field.
Actually no. Often, interrelated backports are combined into a single
PR, but your PR ID field (and the current practice of putting the full
URL in the description) works not only for 1:1 but also N:1 (multiple
trackers in a single PR).
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.
Just to clarify - is this the URL of the *backport PR*, or a link to the
*original PR* that is being backported?
When the master tracker is copied to create the backport trackers, the
description is wiped. I.e. a fresh backport issue will have an empty
description. When the backport PR is opened, its full URL is placed in
the description.
To find out the URL of the master PR, one clicks on the "Copied from"
link to get to the master tracker issue.
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.
The primary intention of this field is to have a consistent way of
associating a pull request with the corresponding tracker issue, as
there did not seem to be a consistent / reliable method for doing so
(other than pasting the URL into a comment). I think it does not matter
if the issue is an actual bug/feature or a backport issue - they all
have a corresponding PR on github that addresses the issue.
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.
Hmm, but the entire URL is still available? You right-click on the ID
and select "Copy Link Location". Or am I missing something?
When you click on PR URLs hundreds and thousands of times, there is a
big difference between clicking once on a full URL that is staring at
you front-and-center in the description (see my second point, above),
and going through the process you describe, on a custom field.
In short, the problem the PR ID field is solving has already been solved
for backports, and applying it on the backport workflow would be a step
in the wrong direction IMO. Like fixing something that isn't broken.
Let me ask this: why does it matter whether backport issues have the URL
in the description or in a custom field?
Nathan
