what if tracker url changes?

[Frits Jalvingh]

Ok, I think we understand each other ;-) Just to summarize:


On Thu, 2010-11-18 at 19:39 -0500, Aaron Bentley wrote:
> On 11/18/2010 04:37 PM, Frits Jalvingh wrote:

> We have a globally unique identifier-- we just need a way to map it to
> the appropriate resource.  This problem is no worse than we would have
> with any other globally unique identifier.
Of course. I just want that identifier to be separate from the bug#.

> 
> > 2. Why does a tuple [tracker GUID, bugID] not uniquely identify a bug?
> 
> It does.  Such a tuple is, itself, a globally unique identifier.
> (Provided bugID is unique with respect to the GUID.)
> 
> > Different discussion, and again- where is GUID-ness of email addresses
> > needed? To uniquely identify users?
> 
> Yes.
I understand in the context of Launchpad.

> > Please remember that I have no problem with "preferring some globally
> > unique ID" related to the bug- I just want bug ID and tracker GUID
> > separate, and lookup for tracker url-for-a-specific-action configurable
> > independent of it.
> 
> When you said "separate" earlier, I didn't understand that a tuple of
> (GUID, bug-id) would satisfy that requirement.
Thanks, that is the most important point indeed.


> >> Bazaar generally does not attempt to provide the guarantee that an
> >> identifier is the only one that identifies a resource.
> > That is not the issue. It would be nice if it IS a correct
> > representation if you're using an URL.
> 
> It seemed like you were making it an issue.  In any case, you seem to be
> suggesting that a GUID + bugID combination which, by itself, has no
> intrinsic meaning is superior to a URL, which has an intrinsic meaning,
> because that intrinsic meaning may become stale.  For myself, I think
> the URL is superior - that some intrinsic meaning is better than none -
> but I can understand that others might feel differently.
No, I would love intrinsic meaning if that is possible in a way that
would combine bugID and tracker URL/URN in a way that they can be
separated in a single well-defined way. But I see the changeability of
tracker URLs (giving cause to the need to "translate" them later on) as
a big force against that ability.


> >> Similarly, email addresses also change.  Would you change how user-ids
> >> are handled also?
> > Is there a clear use case where that is needed? Does an email address
> > consist of multiple parts, like tracker and bug number?
> 
> Sure.  Email addresses usually contain an @ symbol that separates the
> identification of the user from the identification of the domain.
Although true this domain does not usually tell you anything about that
user- it imposes no other information. It does not somehow divide users
in "classes of users" (except that unrelated ones can have the same
domain name). This means that for information purposes the two really
are one. The only one usually interested is the email system which needs
it to lookup the MX record...

This differs from the bug case because there the tracker URL defines all
bugs as "the class of bugs defined in this tracker".


> > So- no. There is no problem we /can solve/ around this.
> 
> Just as URLs can change, email addresses can change.  We could solve
> this by providing a way to map old email addresses to new addresses,
> just as we could provide a way to map old URLs to new URLs.
True, of course; but there you would map the entire email address to
something else. Not "all users in domain aaa.xxx move to domain
bbb.yyy". There is also not much of a usecase I think ;-)


> >> We cannot separate the tracker from the bug id.  We don't have a way of
> >> identifying the bug if we do that.
> > I don't get that. A compound key is unique too.
> 
> I did not get the impression that you were talking about a compound key.
>  I got the impression that you were talking about storing only the bug
> id, and having the bugtracker be implied by the branch, or perhaps by
> local configuration.
Nooooo ;-) No, the bugtracker should be well-defined in each bug logged,
so every bug must have tuple like [bugtracker URL, bugid].


> >> We want there to be no ambiguity about what bug is being referred to.
> > Well, it would at least be ambiguous when a tracker URL changes. It
> > would be less ambiguous if that could happen without the internal
> > representation (guid+bugid) having to change.
> 
> I don't see using a URL as significantly worse than using an arbitrary
> GUID.  Both can be transformed into a usable URL.  A URL has the
> advantage of being meaningful most of the time without needing to be
> remapped.
The key word is "transformed" here ;-)

I have no problem at all with an URL as long as bug storage separates it
from the bug #. In my book an ideal way would be something like storing
them as:
["https://bugs.launchpad.net/bzr/+bug/", "395731"]

To define a tracker we would do something like:

bugzilla_domui_url = http://bugzilla.etc.to/

allowing

bzr commit --fixes domui:954

This would default to store bugs like:
["http://bugzilla.etc.to/", "954"]

When displaying bug entries in log we can map this to a "display" URL
on-the-fly using that same definition and the knowledge it is bugzilla:

http://bugzilla.etc.to/show_bug.cgi?id=954

Now in case the tracker URL changes because I get my own domain
www.domui.org I need to force remap of all old bug URL- but the key does
not change. So I add to the config file (this is new):

bugzilla_domui_remap = http://bugzilla.domui.org/

Now: all bugs /stored after this/ still keep their original key:
["http://bugzilla.etc.to/", "21342"]

But log on-the-fly translates to

http://bugzilla.domui.org/show_bug.cgi?id=954

for old /and new/ entries.

Fun part is that because of this it will be easy to do things like
marking the commit(s) that fix a bug inside the tracker itself, by
issuing a RPC call to it. Easy because tracker URL and bugID can be
easily split.

The only other point was the location of that config file...

Frits