[launchpad] temporary subscription to packages

[Stephan Hermann]

Hi,

On Thursday 05 January 2006 01:44, Matthias Klose wrote:
> Summary: Ubuntu developers don't have a strong relation to packages as
> i.e. seen in Debian, however current launchpad doesn't have any means to
> describe such loose relations between a person and a package. Something
> like temporary subscription to a package might be useful for people who
> fix one thing in a package and then go on to the next package/thing to
> fix, otoh it will cost some resources to implement. Polling for
> feedback, if others consider such a feature as beeing useful. Please add
> the feedback as a reply or to the bug report mentioned below.
>
> The feature request is at https://launchpad.net/products/malone/+bug/3882
>
> Launchpad/Malone allows subscribing people and groups of people to a
> package and monitor that package for bug reports, uploads, build status,
> etc. When working on packages that you are not subscribed to, or when
> working on package which belongs to a team, no notification is sent to
> the uploader. It would be useful to get all this information on this
> package for a limited period only (i.e be informed of build failures,
> installability problems, new bug reports regarding your upload, etc).
> This can be done by
>
> - subscribing to the package, then unsubscribing again. this puts the
>    burden on the uploader, and is likely to be forgotten.
>
> - have launchpad look at the uploader field and the person who signs
>    the upload and subscribe/unsubscribe the person(s) automatically.
>    the length of subscription can
>    - either be a fixed amount of time
>    - some state information (i.e. package built on all archs, package
>      installable on all archs, no new bugs for some time, next version
>      uploaded by somebody else).

Well, launchpad is showing the relations between upstream source and the 
package and the distribution where this package is in.

If we have something like:

	these packages belong to distro main team
	these packages belong to distro universe team

	these packages belong to distro whatever team

This would be nice. With this in mind and thinking about the upcoming buildd 
structure and launchpad I think it would be a good idea to have some 
relationship between the Changed-By field and the build logs.
If a source package FTBFS on the buildd then the changed-by contact should be 
contacted directly via email.
In the case that there is a sponsored upload, so changed-by and uploaders 
address is different, both contacts should be mailed, so that the uploader 
can see if the sponsorship was worth it :)


> Currently an uploader has to poll this information from different
> sources, which takes some effort and is likely to be forgotten, if the
> number of packages increases.

This is the duty of the team/maintainer at all. Doesn't matter if we have 
something like this implemented or not.

> If something like this is beeing implemented, there are surely more
> things to spec out, i.e.
>
> - Would this be a default setting?

I would say yes

> - How would you turn it on/off?

You changed the package, so you have to be interested. IMHO no need to turn it 
off. 

> - How would Malone communicate to the bugmail recipient why  they're
>    getting bugmail all of a sudden for a package?

I think if it's a working and general solution, the people who are working on 
the distribution will know why. I don't see this difficulty.

> - How would Malone communicate when this bugmail will stop?

It shouldn't stop. It can change the communication to a different 
changed-by/uploader contact, but should never stop.

> - Is approaching this kind of complexity in the Malone UI worth the
>    benefits that will be gained by users?

I think this is more a backend thing.

Regarding bugreports, thinking about the package -> distro whatever team 
selection and the distro whatever team mail address, it will go to a mailing 
list e.g. for normal bug reports, just like it is today, well not today, 
because dholbach is triaging the motu bugs.

>
> Is this worth implementing?

for sure.

regards

\sh