Closed
Bug 532350
Opened 15 years ago
Closed 15 years ago
Can't add Debian bug URLs to a bug using "See Also"
Categories
(Bugzilla :: Creating/Changing Bugs, enhancement)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.6
People
(Reporter: reed, Assigned: reed)
References
(Depends on 1 open bug)
Details
Attachments
(1 file, 2 obsolete files)
1.15 KB,
patch
|
mkanat
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 2•15 years ago
|
||
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 → ---
Comment 3•15 years ago
|
||
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.
Comment 4•15 years ago
|
||
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
Comment 5•15 years ago
|
||
(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.
Comment 6•15 years ago
|
||
ok, fine, so we need to file a new bug for the error message...
Severity: normal → enhancement
Target Milestone: Bugzilla 3.4 → ---
Assignee | ||
Comment 7•15 years ago
|
||
Untested patch to add support for Debian BTS URLs.
Assignee: create-and-change → reed
Status: NEW → ASSIGNED
Attachment #415682 -
Flags: review?(mkanat)
Assignee | ||
Comment 8•15 years ago
|
||
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)
Comment 9•15 years ago
|
||
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.
Assignee | ||
Comment 10•15 years ago
|
||
(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.
Comment 11•15 years ago
|
||
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).
Assignee | ||
Comment 12•15 years ago
|
||
(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.
Comment 13•15 years ago
|
||
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
Comment 14•15 years ago
|
||
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 15•15 years ago
|
||
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+
Comment 16•15 years ago
|
||
(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?
Comment 17•15 years ago
|
||
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.
Comment 18•15 years ago
|
||
Ah, so reed, just convert it into a plugin and add a hook here. :)
Flags: approval?
Flags: approval3.6?
Assignee | ||
Comment 19•15 years ago
|
||
(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.
Comment 20•15 years ago
|
||
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
Assignee | ||
Comment 21•15 years ago
|
||
Indeed, you can't claim comment #17 while still supporting Launchpad.
Flags: approval?
Flags: approval3.6?
Comment 22•15 years ago
|
||
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.
Assignee | ||
Comment 23•15 years ago
|
||
(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.
Comment 24•15 years ago
|
||
Okay. I'm interested only if there are current plans or anybody who is working towards having plans or (publicly) thinking about having plans.
Comment 25•15 years ago
|
||
Note that this patch is bitrotten due to the checkin of the Google Code one.
Assignee | ||
Comment 26•15 years ago
|
||
Attachment #415687 -
Attachment is obsolete: true
Attachment #435866 -
Flags: review?(mkanat)
Attachment #415687 -
Flags: review?(mkanat)
Updated•15 years ago
|
Attachment #435866 -
Flags: review?(mkanat) → review+
Updated•15 years ago
|
Flags: approval?
Flags: approval3.6?
Flags: approval3.6+
Flags: approval+
Target Milestone: --- → Bugzilla 3.6
Assignee | ||
Comment 27•15 years ago
|
||
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: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•