what if tracker url changes?

[Frits Jalvingh]

On Tue, 2010-11-23 at 13:34 +1100, Martin Pool wrote:
> I think the way forward is to do any or eventually all of the following:
> 
> * Document that the 'fixes' information is actually a more abstract
> URI for a bug, not necessarily a URL through which you get an html
> representation of it.
No: I would propose to /change/ the "fixes" information into a tuple
[bug tracker ID, bug]. Where the tracker ID can be the tracker's root
URL as a basic attempt to get uniqueness. If you only document a quite
abstract change it will not solve the problem of getting separate bugIDs
and tracker URLs to support other functions than just "show me".
This can be made mostly backwards compatible (if at all needed) I think
by just adding this as extra data to the bugs property and exposing in
in a reasonable way.

> * Add an extension point by which we can get one or more urls (or more
> abstract actions) given a bug URI: they might include http/html, api,
> short human name, etc.  Use this when showing bugs.
> * Define the emacs tracker builtin to bzr
This reduces the need to actually solve the underlying problem (missing
versioned properties).... Will you add all other "winers" too? ;-)

> * Make it easier to define new tracker shortcuts in the versioned tree
Yes! Hopefully using some kind of versioned props (base reason I reacted
to this all).

> * Add a way to check an entered bug is valid/correct when entered (eg
> by an api ping, showing the title)
>