Sorting out upstream and project bugtrackers

[James Henstridge]

On 27/08/06, Andrew Bennetts <andrew at canonical.com> wrote:
> James Henstridge wrote:
> [...]
> >
> > If we want to have a single bug tracker entry for SF, then we'll need
> > to make the "remote bug number" consist of three numbers:
> >  * the bug ID
> >  * the tracker ID (e.g. Python bugs, Python patches)
> >  * the project ID (e.g. Python)
> [...]
> >
> > While the bug ID is unique accross SF, we can't construct a URL for it
> > without the other two numbers, so they need to be stored somewhere.
> > Yes this sucks.  No we can't do anything about it.
>
> What about http://sourceforge.net/support/tracker.php?aid=nnnn (where nnnn is
> the bug ID)?
>
> I discovered this when following a link from an email to a patch in the Python
> patch tracker:
>     http://sourceforge.net/tracker/index.php?func=detail&aid=1531963&group_id=5470&atid=305470
>
> But it appears the patch got reclassified into a bug, resulting in a page saying
> "ERROR: Artifact: Invalid ArtifactID; this Tracker item may have moved to a
> different Tracker since this URL was generated -- [Find the new location of this
> Tracker item]".  The bracketed text was a hyperlink to:
>     http://sourceforge.net/support/tracker.php?aid=1531963
>
> Which redirected to:
>     http://sourceforge.net/tracker/index.php?func=detail&aid=1531963&group_id=5470&atid=105470
>
> (the atid is one digit different).

Wow.  I don't think I ever noticed this.  If they have this
redirector, I wonder why they bother including group_id and atid in
the URL?

This should help simplify the SF bug watch support a bit though.
Thanks for the tip.

James.