Launchpad will sync comments and link back to all bug watches, even those not linked to a bug task
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Gavin Panella |
Bug Description
What happens:
If a bug has a bug watch against an upstream bug, even if that upstream bug has nothing to do with the actual bug, Launchpad will still sync comments for that bug watch and add a back link, where possible.
For example, bug 454166 was fixed by a change to a package and the changelog was posted to the bug as a comment by the LP Janitor. This comment contained the URL of an upstream bug, so a bug watch was created for that upstream bug.
Checkwatches then imported the comments from that upstream bug, even though the upstream bug had nothing to with the Launchpad bug. (see http://
Also, complaints have been made upstream about the automatic back-links that Launchpad makes. If an bug is mentioned in a Launchpad bug comment and thus has a watch generated for it that watch will then be linked back to the upstream bug, even if it's not even tangentially related to the Launchpad bug in question.
What should happen:
Checkwatches should only sync comments and backlink when a bug watch is actually linked to a BugTask. That will eliminate this problem (unless someone adds a nonsensical BugWatch to a BugTask, but we can't prevent users from doing odd things all the time).
Related branches
- Abel Deuring (community): Approve (code)
-
Diff: 80 lines (+20/-4)4 files modifiedlib/lp/bugs/doc/checkwatches.txt (+3/-1)
lib/lp/bugs/doc/externalbugtracker-linking-back.txt (+11/-0)
lib/lp/bugs/scripts/checkwatches.py (+5/-3)
lib/lp/bugs/scripts/tests/test_bugimport.py (+1/-0)
Changed in malone: | |
status: | New → Triaged |
importance: | Undecided → Low |
tags: | added: bugwatch |
Changed in malone: | |
assignee: | nobody → Gavin Panella (allenap) |
milestone: | none → 10.02 |
Changed in malone: | |
status: | Fix Committed → Fix Released |
Created an attachment (id=248671)
What a menu looks like under 3.0a1
If you compare this to 2.0, you can tell that the right pixel is cut off of each line of text. It is most obvious on the lowercase 's' on the bottom two options shown in that picture. The left pixel is also cut off of each line, but it is harder to tell. All of the text is clearly "dimmer" looking and not properly aliased for cleartype display, causing it to not look as sharp as it should and does under 2.0 and other browsers. Another small change noticeable is the space between the T and F on the second and third lines is 1 pixel less in 3.0a1 for some reason.