Closed Bug 532350 Opened 15 years ago Closed 14 years ago

Can't add Debian bug URLs to a bug using "See Also"

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

3.4.4
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 3.6

People

(Reporter: reed, Assigned: reed)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

I want to add http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475166 to bug 435683 via the "See Also" mechanism, but when I try, I get the following error message:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475166 is not a valid URL to a bug. Bug URLs should point to show_bug.cgi  in a Bugzilla installation. 

Debian doesn't use Bugzilla, and I see no reason for the "See Also" feature to be Bugzilla-specific (Launchpad is supported natively, and it's not Bugzilla), so either support for Debian bug URLs should be added to add_see_also() in Bugzilla/Bug.pm, or that check should just be removed completely.

I'll write a patch based on which of the above is wanted.
I'd request that something support a limited regexp parser which converts an input into an output or returns an error.

Preferably a database table driven thing so that we could just add mappings later instead of patching the codebase.

It'd be nice to be able to add support for trac and a couple of others w/o patching bugzilla. (the database field values should be contributable).

Ideally, it's 4 fields: parser_name, description, capture_re, replacement_value. Bugzilla builtins would have a bugzilla_ prefix to the name so they don't conflict.
This is not a bug, but a request for improvement (enhancement), so this won't be taken for 3.4 nor 3.6.
Severity: major → enhancement
Target Milestone: Bugzilla 3.4 → ---
The reason that See Also does not take URLs for other trackers is that the feature will be enhanced to retrieve data from the other bug-tracker about the bug. This was originally planned for 3.4 but development priorities ended up excluding scheduling for the feature. I suppose it will make it into 3.8 at this point.

Though support for individual custom bug-trackers would be possible, I think what would be better would be to add hooks that would allow extensions to define support for additional bug-trackers, so that everybody could add their home-grown system to support in the See Also field.
How about if we fix the error message to say what it really means then, instead of assuming it's supposed to be a Bugzilla URL when it also supports launchpad?  (like list off all of the trackers it *does* support in the error).
Severity: enhancement → normal
Target Milestone: --- → Bugzilla 3.4
(In reply to comment #4)
> How about if we fix the error message to say what it really means then, instead
> of assuming it's supposed to be a Bugzilla URL when it also supports launchpad?

This won't fix this bug. Mentioning LaunchPad won't let you add Debian URLs. That's really a separate bug, not this one.
ok, fine, so we need to file a new bug for the error message...
Severity: normal → enhancement
Target Milestone: Bugzilla 3.4 → ---
Attached patch patch - v1 (obsolete) — Splinter Review
Untested patch to add support for Debian BTS URLs.
Assignee: create-and-change → reed
Status: NEW → ASSIGNED
Attachment #415682 - Flags: review?(mkanat)
Attached patch patch - v2 (obsolete) — Splinter Review
Fix whitespacing and always check $bug_id, as it could be undef from detaint_natural() (thanks LpSolit).
Attachment #415682 - Attachment is obsolete: true
Attachment #415687 - Flags: review?(mkanat)
Attachment #415682 - Flags: review?(mkanat)
Does the Debian BTS have:

* An API that will allow us to get information about the bug being linked to?
* A similar field that can be used to link back to Bugzilla?

Normally I'd be against supporting home-grown trackers in Bugzilla. I included Launchpad because (a) Canonical funded the work that allowed me to implement see_also and (b) Launchpad is a single tracker that tracks a LOT of projects--enough that it's one of the major open-source bug-tracking systems.

The Debian tracker just tracks Debian packages, AFAIK. So I'm not sure that I want a piece of code in Bugzilla itself (which we have to maintain, even in the face of changes to the Debian BTS) as opposed to a plugin maintained by some external entity. This would require hooks, but I'd be definitely interested in seeing those hooks implemented.
(In reply to comment #9)
> Does the Debian BTS have:
> 
> * An API that will allow us to get information about the bug being linked to?

Yes, http://wiki.debian.org/DebbugsSoapInterface

> * A similar field that can be used to link back to Bugzilla?

Possibly the "forwarded" attribute, though only in the case that a Debian bug has been forwarded upstream to Bugzilla. There doesn't seem to be an exact "see also" field in the "related" sense.

> Normally I'd be against supporting home-grown trackers in Bugzilla. I included
> Launchpad because (a) Canonical funded the work that allowed me to implement
> see_also and (b) Launchpad is a single tracker that tracks a LOT of
> projects--enough that it's one of the major open-source bug-tracking systems.
> 
> The Debian tracker just tracks Debian packages, AFAIK. So I'm not sure that I
> want a piece of code in Bugzilla itself (which we have to maintain, even in the
> face of changes to the Debian BTS) as opposed to a plugin maintained by some
> external entity.

Bugzilla is used by a large number of open source software projects, including GNOME, KDE, GCC, etc., and it's very common for these projects (including Mozilla in some Linux cases) to need to link to Debian bugs. This is a needed feature.

Now, as discussed on IRC earlier between justdave, LpSolit, and myself, if you want to rip out all support for other BTS except for Bugzilla and then put the rest all into _one_ extension/plugin, then I wouldn't be opposed, but if not, Debian has just as much a right to be supported as Launchpad does.
Great, thanks for the API info.

I think the argument of how many OSS projects need to link back to Debian is a sufficient argument for inclusion in the core (though the option of moving everything to a plugin is also an option, though that decreases functionality for the external bug-trackers if they want to implement an API to add links to us).
(In reply to comment #10)
> > * A similar field that can be used to link back to Bugzilla?
> 
> Possibly the "forwarded" attribute, though only in the case that a Debian bug
> has been forwarded upstream to Bugzilla. There doesn't seem to be an exact "see
> also" field in the "related" sense.

I came across this today: http://bts-link.alioth.debian.org/

bts-link seems to be Debian's version of an advanced "see also" that pulls remote status and things like that.
Once the entire See Also system is implemented for the two systems we currently support, adding additional systems can be considered.
Depends on: bz-seealso
Max: I think you are letting the best be the enemy of the good here. 

Your plans for See Also aren't going to happen for 3.6 (comment 2 and comment 3) but support for other systems is wanted, and patches are available now (this bug and bug 533121). If you don't accept them for 3.6, it's going to be up to a year before this function will be available in a stable Bugzilla. What is the gain to users from making them wait that long?

Gerv
Comment on attachment 415687 [details] [diff] [review]
patch - v2

This is working fine, and I see no reason not to take it. r=LpSolit
Attachment #415687 - Flags: review+
(In reply to comment #13)
> Once the entire See Also system is implemented for the two systems we currently
> support, adding additional systems can be considered.

I don't see why this is a requirement. We can move the code elsewhere if needed, later.
Flags: approval?
Flags: approval3.6?
  Once we add this, we are making a sort of API guarantee that we will support this into the future. Once we add summaries and statuses for other trackers, people will then expect us to add summaries and statuses for the Debian bug tracker. Then, if the Debian bug tracker changes its API, we have to change every stable branch of Bugzilla that is capable of displaying summaries and statuses for external trackers. Any other features that we add to external bug trackers will also have to be added, *by us*, for the Debian bug tracker. 

  As you can see, that just doesn't scale to very many bug trackers. I'm OK with adding Trac, Jira--things like that, because they track a *lot* of projects at a lot of different places. But here you're adding code for *just one custom bug-tracker*, for *just Debian*.

  If instead, this is a plugin, then the plugin author can just keep track of any changes--much simpler. The plugin author is invested in maintaining the intergration for this singular bug-tracker, and if it fails, it doesn't put any further burden on the Bugzilla project. So, that's why I think this would be better off as a plugin.
Ah, so reed, just convert it into a plugin and add a hook here. :)
Flags: approval?
Flags: approval3.6?
(In reply to comment #17)
>   As you can see, that just doesn't scale to very many bug trackers. I'm OK
> with adding Trac, Jira--things like that, because they track a *lot* of
> projects at a lot of different places. But here you're adding code for *just
> one custom bug-tracker*, for *just Debian*.

It's not just *for* Debian, though... If this was just for one company/group, I'd agree, but it's not. You need to take into account the number of Bugzilla instances that will use this functionality. Considering most of the largest Bugzilla installations are all Linux-related, Debian bug tracking is extremely important, as every distro and any vendors that deal with Debian directly or indirectly needs to track bugs in Debian's bug tracker.
I think the correct metric for importance is not number of installations, but the size of those installations and the likelihood that Bugzilla's core audience (open source projects) will want to interact with those installations. On that basis, both the Debian BTS and Launchpad (which are both open source yet both have only one significant installation) qualify.

I see Max's point about us having to maintain the code afterwards, but that's true of any new code that implements a new feature. Is there something specifically difficult to maintain about the Debian integration?

Gerv
Indeed, you can't claim comment #17 while still supporting Launchpad.
Flags: approval?
Flags: approval3.6?
Comment on attachment 415687 [details] [diff] [review]
patch - v2

  Launchpad (much like Google Code) tracks many, many projects. So it's not like the Debian bug-tracker, which just tracks Debian packages and issues with Debian.

>+    elsif ($uri->authority =~ /^bugs.debian.org$/) {

  If you're going to do a ^$ match without a /i, you might as well do "eq".

  Is that the only domain (excluding URL shorteners--I mean canonical domain name) that can resolve to a Debian bug?

  Does Debian have any plans to ever change their bug-tracking system?

  Otherwise, this patch looks OK.
(In reply to comment #22)
> (From update of attachment 415687 [details] [diff] [review])
>   Launchpad (much like Google Code) tracks many, many projects. So it's not
> like the Debian bug-tracker, which just tracks Debian packages and issues with
> Debian.

I would put forth that Debian tracks more projects than Google Code, however.

> >+    elsif ($uri->authority =~ /^bugs.debian.org$/) {
> 
>   If you're going to do a ^$ match without a /i, you might as well do "eq".

Sure, will change on check-in.

>   Is that the only domain (excluding URL shorteners--I mean canonical domain
> name) that can resolve to a Debian bug?

Yes, see http://www.debian.org/Bugs/.

>   Does Debian have any plans to ever change their bug-tracking system?

I'm sure some changes will come at *some* point in the future (you're just using weasel words there), but I don't know of any existing plans to make wide-scale changes at this present time.
  Okay. I'm interested only if there are current plans or anybody who is working towards having plans or (publicly) thinking about having plans.
Note that this patch is bitrotten due to the checkin of the Google Code one.
Attached patch patch - v3Splinter Review
Attachment #415687 - Attachment is obsolete: true
Attachment #435866 - Flags: review?(mkanat)
Attachment #415687 - Flags: review?(mkanat)
Attachment #435866 - Flags: review?(mkanat) → review+
Flags: approval?
Flags: approval3.6?
Flags: approval3.6+
Flags: approval+
Target Milestone: --- → Bugzilla 3.6
Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/
modified Bugzilla/Bug.pm
Committed revision 7114.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/3.6/
modified Bugzilla/Bug.pm
Committed revision 7072.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: