I've budgeted 40 hours for this. I don't expect every external tracker to be done. If we cover Bugzilla, JIRA, PHP and any other heavily used tracker, that will be good enough. -- simon
In laymen's terms this is the change we are going to be making: 1) Enforce that the External Bug value looks valid (e.g. is an integer for Bugzilla bugs) 2) Update the summary, status and priority of these external bugs, assuming the bug/issue is publicly visible, and there is an RPC/REST interface available. This is true for Bugzilla and JIRA, which make up a lot of the external trackers.
(In reply to comment #2) > 1) Enforce that the External Bug value looks valid (e.g. is an integer for > Bugzilla bugs) Or an alias?
(In reply to comment #3) > Or an alias? Not for an external Bugzilla bug. Aliases can changed to point to a different bug (or be removed). This would make the link useless. By enforcing an integer for a Bugzilla bug, you are ensured that the bug link remains valid (doesn't help if they nuke a database, and start counting from one again, but that is a whole different issue) -- simon
I was thinking of the way we use aliases for CVEs, for example, which might be *better* than referencing a specific bug number. I would think this is a matter for the user to decide based on the context, not something for a 'one size fits all' policy.
Actually a more important reason that it cannot be an alias is the change we are going to make is actually track the external tracker. For this to happen (for Bugzilla) we need the bug id, as the RPC call won't accept an alias in the Bug.get value. -- simon
*** Bug 1012162 has been marked as a duplicate of this bug. ***