Bug activity doesn't indicate changes to the product

Christian Reis wrote:
> Public bug reported:
> https://launchpad.net/malone/bugs/5443
>
> Affects: malone (upstream)
> Severity: Normal
> Priority: (none set)
> Status: New
>
> Description:
> The bug activity page doesn't indicate changes to the product. See for
> instance:
>
> https://launchpad.net/products/firefox/+bug/5430/+activity
>
> I had expected to see there Product: old:rosetta new:firefox. There is
> nothing, though.

It is just a log of Bug activity, which has nothing to do with the Products
or the Distributions or the DistroReleases or the DistroArchReleases or the
ProductSeries or the Registrant of the Product/Distribution/DistroRelease etc.

Why should it? The only rationale I can see is to notify people that the URL
has changed. A better solution to this use case is to ensure that old bug
URLs redirect to the correct context rather than return a 404

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

On Wed, Dec 07, 2005 at 02:51:13AM -0000, Stuart Bishop wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/5443
>
> Comment:
> Christian Reis wrote:
> > Public bug reported:
> > https://launchpad.net/malone/bugs/5443
> >
> > Affects: malone (upstream)
> > Severity: Normal
> > Priority: (none set)
> > Status: New
> >
> > Description:
> > The bug activity page doesn't indicate changes to the product. See for
> > instance:
> >
> > https://launchpad.net/products/firefox/+bug/5430/+activity
> >
> > I had expected to see there Product: old:rosetta new:firefox. There is
> > nothing, though.
>
> It is just a log of Bug activity, which has nothing to do with the Products
> or the Distributions or the DistroReleases or the DistroArchReleases or the
> ProductSeries or the Registrant of the Product/Distribution/DistroRelease etc.

Since status and assignee changes end up in the bug activity, so should
product changes.

> Why should it? The only rationale I can see is to notify people that the URL
> has changed. A better solution to this use case is to ensure that old bug
> URLs redirect to the correct context rather than return a 404

If someone changed a bug task from a valid to an invalid product, at
least I would like to know that it happened, and who did it. If we have
no notifications, someone could change Launchpad bugs to be Firefox
bugs, and we wouldn't know about it.

Actually, Stuart, now that I read what kiko wrote, maybe you
misunderstood? Kiko wasn't talking about changes to the product itself,
but about changing the target of a bug task.

Indeed, I was talking about the fact that the bugtask's product was
changed. I /do/ think that belongs in the Bug activity page -- it's
quite confusing otherwise.

Le 7-Dec-05 à 6:42 AM, Christian Reis a écrit :

> Public bug report changed:
> https://launchpad.net/malone/bugs/5443
>
> Comment:
> Indeed, I was talking about the fact that the bugtask's product was
> changed. I /do/ think that belongs in the Bug activity page -- it's
> quite confusing otherwise.

+1.

Cheers,

--
Brad Bollenbach

Brad Bollenbach wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/5443
>
> Comment:
> Le 7-Dec-05 à 6:42 AM, Christian Reis a écrit :
>
>
>>Public bug report changed:
>>https://launchpad.net/malone/bugs/5443
>>
>>Comment:
>>Indeed, I was talking about the fact that the bugtask's product was
>>changed. I /do/ think that belongs in the Bug activity page -- it's
>>quite confusing otherwise.
>
>
> +1.

We can't do it though without redesigning the bug activity system - if a
product is renamed that has 1000 bugs, we would need to insert 1000 rows
into the database. If a distribution is renamed with 10,000 bugs we would
need to insert 10,000 rows into the database.

If you really want this (and I still personally don't see why product
changes would appear on the bug activity - it has nothing to do with the
bug, and doesn't affect the bug in the slightest), then we need to implement
product activity, distribution activity and distrorelease activity and
interleave the relevant activity logs in the UI. So renaming a product would
add one row to the DB, but the change would appear on all bugs targetted to
that product.

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

Björn Tillenius wrote:

> Actually, Stuart, now that I read what kiko wrote, maybe you
> misunderstood? Kiko wasn't talking about changes to the product itself,
> but about changing the target of a bug task.

Yes - I misunderstood. Sorry for the noise ;)

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

On Wed, Dec 07, 2005 at 04:48:05PM -0000, Stuart Bishop wrote:
> We can't do it though without redesigning the bug activity system - if a
> product is renamed that has 1000 bugs, we would need to insert 1000 rows

Uhm, Stuart, I'm talking about tracking changes in a bugtask's product
field -- retargetting the bugtask to a different product. It has nothing
to do with products being renamed.

This won't be done for 1.1.7, it's better to spend time re-writing the activity log, instead of making improvements to the current implemenation.

Moving this back to triaged until the API work is (at least partly) done.

Fixed in devel r8108.