time based / temporary subscriptions to bug reports (and packages)

Every new feature added to the Malone UI will raise the bar of entry for the new user to an even higher level than it already is.

Is this use case common and important enough to support, or is it YAGNI?

IMO it's very important to be able to track a package if you did upload it and you are not subscribed to it (i.e. doing a one time bug fix). Look at people doing uploads of many packages to achive one thing. That's regularily done for library renamings, version upgrades, merges, etc ...

Debian recently added something like this:

  http://qa.debian.org/developer.php?login=doko%40debian.org

see the bottom of the page (Uploads by <email address hidden>). So this one isn't time based, but holds the information as long as you are the last uploader.

On 2-Dec-05, at 12:17 PM, Matthias Klose wrote:

> Public bug report changed:
> https://launchpad.net/malone/bugs/3882
>
> Comment:
> IMO it's very important to be able to track a package if you did
> upload
> it and you are not subscribed to it (i.e. doing a one time bug fix).
> Look at people doing uploads of many packages to achive one thing.
> That's regularily done for library renamings, version upgrades,
> merges,
> etc ...
>
> Debian recently added something like this:
>
> http://qa.debian.org/developer.php?login=doko%40debian.org
>
> see the bottom of the page (Uploads by <email address hidden>). So this one
> isn't time based, but holds the information as long as you are the
> last
> uploader.

Are there other use cases that you can think of for why you'd want
time-based or temporary package subscriptions?

It might be best to gather those in this bug report.

  affects /products/malone status needinfo

Cheers,

--
Brad Bollenbach

> Are there other use cases that you can think of for
> why you'd want time-based or temporary package subscriptions?

I don't know, but that use case is broad. consider a person beeing in a large team (i.e. MOTU, core developer). maybe you can see something like a team status, but that includes too much information in general. these people should be interested to get a package built on all architectures, and be able to track the status until the package hits the archive on all architectures, plus a period where they are notified about new bug reports in those packages.

> It might be best to gather those in this bug report.

I'll keep the status on "need info", however I don't know what you would like to know about more ...

doko, did you get any responses to your query on ubuntu-devel?

Brad Bollenbach schrieb:
> Public bug report changed:
> https://launchpad.net/malone/bugs/3882
>
> Comment:
> doko, did you get any responses to your query on ubuntu-devel?

yes, there was one reply, you should be on the CC.

I'd find this very handy as well for doing security updates. Virtually every package I upload is effectively an NMU. Currently I just haunt #ubuntu-bugs and check scrollback every day, but I'd like a less error-prone solution to this.

So a workable solution being proposed here is to have a report for bugs in packages which I was the last uploader? That's not nearly as complicated as temporary subscriptions (hint, hint).

Having such a report would certainly be a useful step, but the real point of this is to ensure that uploaders find out about breakage reported in a package they uploaded in a timely fashion, without having to subscribe to all Ubuntu bugs and do complicated filtering. This really needs actual bug mail to be sent out to the last uploader, preferably with an appropriate X-Launchpad-Message-Rationale.

This corresponds to an item on UbuntuInfrastructureNeeds:

  Temporarily adding the uploader as a bug contact for the package being uploaded

    * Rationale: Our development model is such that packages are often uploaded by a developer who has no ongoing relationship with the package. Because they do not receive bug reports for the package, it is easy for them to be unaware of having introduced a regression.