Status "FixCommited" for ubuntu-tasks

[Murat Gunes]

On Wed, 15 Apr 2009 06:31 -0600, "Charlie Kravetz"
<cjk at teamcharliesangels.com> wrote:

> While I can agree with this logic, what do you do when the upstream
> report does not update in launchpad? There are many bugs with upstream
> projects attached, that become fixed upstream but never get a
> launchpad update. They also become fix-released in launchpad without
> the upstream bug having been updated beyond "unknown".

If the upstream status isn't updating, that should mean one of the
following: that Launchpad does not support communicating with that bug
tracker, that the location of the upstream bug tracker is not
registered in Launchpad, or that there is a bug in Launchpad's remote
bug tracker integration.

It would be useful to know if there are exceptions to the above, which
you can outline with a concrete bug workflow example.

> I, personnally, find I must maintain some type of personal list to
> know which bugs have actually been worked upstream because of this
> issue. Not being able to move the Ubuntu bug to fix-committed does
> double the work I must do to find out if the upstream bug has indeed
> been fixed. It also increases the workload for the developers if they
> must go and look upstream for status.

You can perform an advanced search for bugs related to you that are
fixed upstream but not in Ubuntu [1]. It's also possible to list such
bugs via bughelper / python-launchpad-bugs and the Launchpad API.
If/when the request in bug #49752 in Launchpad [2] is implemented, we
will have the ability subscribe to an Atom feed of such bugs too.

> Doesn't that defeat the purpose of even having the upstream project?

I don't think so, but this discussion does echo some points previously
raised against the distinction between "Fix Released" and "Fix
Committed" [3] in a different context.

On Wed, 15 Apr 2009 09:17 -0500, "C de-Avillez"
<hggdh2 at gmail.com> wrote:

> For the argument that a bug fixed upstream can be changed before
> making it to a distribution point: yes, it can. It can also be changed
> after the distribution point, so this argument does not give any
> points either way. Do do cherry-pick upstream fixes, after all.

I may be misunderstanding you, but for the Ubuntu task, we are mainly
interested in the status of the bug before the distribution point(s). If
the upstream code changes after a distribution point to cause the bug
again, and this actually manifests itself in the current Ubuntu
development branch, the Ubuntu task can be reopened.

[1] http://tinyurl.com/dz6fr6
[2] https://bugs.launchpad.net/malone/+bug/49752
[3] https://bugs.launchpad.net/malone/+bug/163694