resolved_upstream list does not do product / source package matching
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Launchpad itself |
Low
|
Unassigned |
Bug Description
Right now https:/
- bug 37711 (Scribus Upstream Invalid, scribus Ubuntu Invalid, scribus-qtimm Ubuntu Confirmed) - no product / source package matching.
Thanks in advance. :-)
Related branches
Changed in malone: | |
assignee: | nobody → gmb |
milestone: | none → 2.1.9 |
Björn Tillenius (bjornt) wrote : | #1 |
Changed in malone: | |
status: | New → Incomplete |
milestone: | 2.1.9 → 2.1.10 |
Daniel Holbach (dholbach) wrote : | #2 |
It would be very very very very nice (with sugar on top of it) to have some kind of list that basically gives us "Stuff that was fixed somewhere, we just need to grab from some place".
The "... bugs fixed elsewhere" link on https:/
Right now bugs like the one listed above turn up on that list because the source package - Launchpad product matching is not considered.
Graham Binns (gmb) wrote : | #3 |
This isn't going to make it for 2.1.10; pushing it off for a cycle.
Changed in malone: | |
milestone: | 2.1.10 → 2.1.11 |
Graham Binns (gmb) wrote : | #4 |
I'm unclear: are we going to push ahead with this? I'm going to untarget this for the time being.
Changed in malone: | |
milestone: | 2.1.11 → none |
I would also like to see this. At least to have an option to turn on source-
A good example is bug #4188 . Which turns up in the bug list when searching for gnome-panel bugs that have been resolved upstream, although only the upstream bug for the nautilus project has been resolved upstream.
Thanks.
Changed in malone: | |
status: | Incomplete → Confirmed |
Changed in malone: | |
assignee: | Graham Binns (gmb) → nobody |
Since I am still interested in this feature, I helped myself with the Launchpad API. It's basically the following (Example: "totem"):
>>>
LP = Launchpad.
UBUNTU = LP.distribution
package = UBUNTU.
project = package.
package_col = package.
project_col = project.
# I am using the split-construct for performance, because that's the only way
# to get the bug number, without requesting a new object (t.bug.id)
package_bugnos = set([str(
project_bugnos = set([str(
# Now I just have to look at the intersection which is basically a
# product/
matches = package_
>>>
That's just an idea I had. I would appreciate feedback. Thanks.
Just a note: For further performance it's recommended to replace
package_col = package.
with
package_col = package.
Changed in launchpad: | |
status: | Confirmed → Triaged |
importance: | Undecided → Low |
Daniel Holbach (dholbach) wrote : | #8 |
This looks like the flipside of bug 829074.
Abel Deuring (adeuring) wrote : | #9 |
My work on bug 829074 will just implement Bryce's suggestion to optionally limit the search results to bugs that have a bugtask on the project that referenced by the packaging link. UI wise, there will be two radio buttons ,like so
Upstream target
(x) All possible upstream targets
( ) [name odf the upstream project]
But I can extend this to also present the options "select upstream project" and "select upstream source package", where you can explicitly specify any project or (Debian) source package. A search would then return only those bugs that have a bug task for the given upstream project/source package. (Or, in the case of "Show bugs that are not known to affect upstream ", bug that do not have an usptream task.)
This option would only be available for searhes on source packages and on distro source packages.
Daniel, is this roughly what you have in mind?
Changed in launchpad: | |
assignee: | nobody → Abel Deuring (adeuring) |
status: | Triaged → In Progress |
Abel Deuring (adeuring) wrote : | #10 |
Set back to "Triaged" because I don't see any way to fix this without adding ca 500 or 800LOC, thus violating the new policy https:/
Changed in launchpad: | |
status: | In Progress → Triaged |
Changed in launchpad: | |
assignee: | Abel Deuring (adeuring) → nobody |
Daniel, are you really sure you want this behaviour? Doing this will require all packages you're interested in to be linked to upstream projects. I fear this might break things for other users.