Currently, values of See Also are constrained by a regular expression that allows only certain classes of URL ("bug type links"). "See Also" was originally designed and remains, intended by upstream, to only contain these kinds of links. The pattern match list is also not runtime configurable, but is defined in code. FreeBSD's Bugzilla instance has added certain additional URL patterns to the pattern match over time, to allow additional popular 'issue' type links (such as GitHub issues and pull requests). We have also received requests over time to add additional patterns to the match to support other well-known services (see this issues See Also list) There is a case to be made for not constraining See Also values at all, removing the overhead of adding additional patterns, deploying bugzilla updates, etc. This would allow any URL to the See Also list, the only field in Bugzilla currently that allows 'multiple' entries (as opposed to the URL field, singular value). Example cases where this would be useful include referencing mailing list or forum posts, or other third-party URL's in a structured field (See Also) rather than in comments. It would also allow people to take (copy) URL's referenced in issue comments, and put them all in one place. On the other hand, allowing arbitrary URL's in the See Also field could result in additional complexity/confusion, as there are no other annotation/metadata mechanisms for see also values, such as types, comments, titles, etc, so there is no additional context possible. Going down this route, rather than say custom fields (something we've always sought to minimise, or use at all), is challenging if not impossible to 'recover from' without manual intervention, for example if we sought to split out or otherwise modify existing issues, with existing arbitrary url's in See Also, into a different scheme. Some ideas to consider: - Have an area of the main issue display area, display a list of URL's that have been 'mentioned' in the history (in comments). This would obviate the need to modify See Also behaviour and diverging further from upstream. Conversely, this might be problematic if/when issue comments were (ever) paginated, which would require looking up and parsing all issue comment text values to pull out url's, the associated 'url regular expression complexity'. - Create an Bugzilla extension that: a) Moved 'See Also' URL pattern matches from code to be runtime (admin) configurable, AND/OR b) Allowed 'See Also' to 'enable/disable' pattern matching rules.
For pull requests that are linked from bug reports and then closed procedurally (not as a result of readiness to close): a) it's appropriate to remove the URLs b) it would be inappropriate to add exactly the same URLs. To ease transition, can you broaden allowances for the See Also field? To allow modified pull request URLs that have suffixes such as .diff and .patch, for example (using non-existent number 000): https://github.com/freebsd/freebsd-doc/pull/000.diff https://github.com/freebsd/freebsd-doc/pull/000.patch Thanks