With bugzilla widely deployed for a number of projects, there is a growing need to refer to bugs in bugzillas for related projects. For instance, I have to refer to freedesktop bugzilla (http://bugzilla.freedesktop.org), gnome bugzilla (http://bugzilla.gnome.org), XFree86 bugzilla (http://bugs.xfree86.org) and RedHat Linux bugzilla (https://bugzilla.redhat.com). It'd be nice if bugzilla offers a short-cut to refer to bugs in other bugzillas. Currently, bugzilla 'html'izes 'bug #?[1-9][0-9]* [comment #? [0-9]+]'. I'm suggesting that that would be extended to htmlize 'freedesktop:bug 12345 comment 23' for a set of pre-defined (admin-configurable) bugzillas for related projects.
see also bug 134294 for inter-bugzilla dependencies (related, not a dupe)
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.
I like this - it's elegant, it's simple (sort of) and it's exactly what is needed. Some ideas: I think that if implemented we should look at the web standards space and maybe use OAuth for authentication of bugzilla interlinking.
(In reply to comment #4) > I think that if implemented we should look at the web standards space and maybe > use OAuth for authentication of bugzilla interlinking. That's a good idea, I'll see if OAuth could be used for this situation.
Okay, so this is going to become a meta-bug for tracking all the necessary tasks here. Canonical is funding some development on this.
Hasn't this been implemented in Bugzilla 3.4 ? : http://www.bugzilla.org/releases/3.4/release-notes.html#v34_feat_see ?
The feature as it stands in 3.4 only covers three of the four blockers of this bug.
We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.