Show bugs that are not known to affect "official" upstream

[Bryce Harrington]

I want to create a report showing only bugs I need to forward upstream from Ubuntu to the official upstream bug tracker for the source package.

On the advanced bug search page there is an option "Show bugs that are not known to affect upstream" which mostly does this for me, however there is one problem. It excludes bugs that have been linked to *any* upstream project.

So, a common problem I am running into is that someone reports a bug against the Unity upstream project, which they determine is an X driver problem so they change the ubuntu source package task in Ubuntu from unity to an X.org package. This counts as "upstream" since Unity is an upstream project, and gets excluded from my report. However, the bug still needs forwarded to X.org upstream.

One possible solution might be to add another checkbox 'Show bugs that are not known to affect official upstream'. Or the existing 'Show bugs that are not known to affect upstream' to only consider if there are watches that are against the official bug tracker for the source package being searched.

[Micah Gersten (micahg)]

Well, I think the language should be clarified. An alternate bug task is not necessarily an "upstream" bug task. I think upstream should either mean an upstream distro or an upstream project for the package in question. Any other tasks shouldn't be reflected in that query.

[Bryce Harrington (bryce)]

So like, a bug against a ubuntu package that has a watch on a debian bug would count as upstreamed? That seems sensible.

For X.org we generally forward bugs up to freedesktop.org and bypass debian (at their request), but I know other areas of the distro are different.

[Curtis Hovey (sinzui)]

I image the query that provides this report would get all the bugs that affect the distro that also affect a project without a packaging link with the distro. However, I do not think my simplified statement will work for the highlighted case.

Lp does not have a concept of official upstream, though Lp can know which Lp project provides code for a package presence of a packaging link for the distro and project. There is no determination of that project is owned by Canonical, an Ubuntu team, or has code that is 100% hosted in Lp. Ubuntu might have packaging link data like this:
    ubuntu -> xorg-video-intel
    ubuntu -> unity
So retargeting a bug from one upstream to another does help if both have packaging links. the goal would be for every source package in Ubuntu to have a packaging link.

I really do not know how to tell that a bug needs forwarding upstream looking at Lp's data. I think the crux of this issue is that for any ubuntu package, Lp must determine if there is a remote bug tracker for the Lp project. A query that provides this report would get all the bugs that affect the distro that also affect a project that has a packaging link with the distro, and has a remove bug tracker set, but does not have a bug watch. My head boggles at the steps needs to collect this data.

[Bryce Harrington (bryce)]

Yes, it's quite cumbersome. I coded up basically what you describe using launchpadlib calls, but it's pretty slow.

It's in python-launchpadlib-toolkit in a upstream_bug_tracker() routine; pseudocode:

lp_bug_task = {Given}

upstream_product = lp_bug_task.target.upstream_product
if upstream_product is None, then give up

upstream_bug_tracker = upstream_product.bug_tracker

If upstream_bug_tracker is None, then
    project_group = upstream_product.project_group
    if project_group is not None:
        upstream_bug_tracker = project_group.bug_tracker

Now you just check if there's any bug watches against this bug tracker; if so, it's been officially upstreamed; if not, it hasn't.

I imagine the database logic to do this lookup could be more efficient. I'm also sure I've missed some corner case or other. But in my testing it does work, and produces more accurate data than Launchpad's search.

[Francis J. Lacoste (flacoste)]

Escalated by Bryce

[Daniel Holbach (dholbach)]

This looks like the flipside of bug 232545.

[Launchpad QA Bot (lpqabot)]

r14748 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14748) is part of this bug's fix.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r14755 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14755>.

[Abel Deuring (adeuring)]

A few remarks about possible ways to extend the released bug fix:

1. lp:~adeuring/launchpad/bug-232545 (no UI changes -- just the model code) extends the option to limit the upstream related filter to a given source package or DSP. . Would this be a reasonable extension of the current filter options?

2. I noticed that the option "specify an upstream project" is not available in the restful API... Should we add it?

3. Does it make sense to specify another upstream project than the one from the packaging link?