[launchpad] temporary subscription to packages
sh at sourcecode.de
Thu Jan 5 05:24:30 GMT 2006
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
> - 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?
More information about the ubuntu-devel