Package maintainers can't set priorities of their own packages

[Mario Limonciello]

Currently, the only way to set priorities on bugs is to be on the ubuntu-qa team. This doesn't make sense for direct maintainers of the packages. I think that the person (or team) listed as the maintainer of the package should be able to set the priorities of that package directly. They will generally be the ones fixing the bugs, so have a much better idea than someone on the general ubuntu-qa team.

[Diogo Matsubara (matsubara)]

Hello Mario,

by setting priorities, I guess you mean, change the importance field. Is that correct?

[Mario Limonciello (superm1)]

Diogo Matsubara wrote:
> Hello Mario,
>
> by setting priorities, I guess you mean, change the importance field. Is
> that correct?
>
> ** Changed in: malone (upstream)
> Status: New => Incomplete
>
Diogo,
Yes that's exactly what I mean.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

Another couple of use cases of this which I've found over recent weeks...

1) A developer has taken over coding a source package in ubuntu (adept). He's listed as a package contact, but can't change the importance of bugs, so either has to request someone else do it, or cant use priority, triaged and won't fix. He's not a part of ~ubuntu-dev, or ~ubuntu-qa.

2) Ubuntu distributes Amarok in vanilla form, plus an installing mp3 script, so the Amarok Upstream Developers are happy to triage the bugs for us, and work from two bugtrackers instead of one, instead of refilling almost all bugs upstream. The upstream developers are in a team called ~amarok-wolf-brigade, which is listed as a package contact. However, these people cannot access priority, triaged and won't fix either, and so cannot effectively triage their bugs, without input from us.

The second use case is the far more critical - it's unfeasible to put all of these people into ~ubuntu-qa, due to their number, and the fact that we really only want them to be able to triage Amarok and related packages anyway, as that's what they're working on. Upstreams are not adverse to using launchpad to get more bugs from, if it's easy for them to do so.

[Christian Reis (kiko)]

Now that we've filed bug 191809 I am curious as to one thing: how would we actually be able to tell who is "The Maintainer" of an Ubuntu package? Is it the Maintainer: field in the latest source package uploaded to Ubuntu? Does it include Changed-By? Is it a union of those? Or a union of all maintainers and changers over time?

I'm asking because in bug 191809 we'd be offering a way to set this explicitly (by using a team or person allocated there) instead of as an implicit consequence of appearing in the package metadata.

[Emilio Pozuelo Monfort (pochu)]

Christian Reis wrote:
> Now that we've filed bug 191809 I am curious as to one thing: how would
> we actually be able to tell who is "The Maintainer" of an Ubuntu
> package? Is it the Maintainer: field in the latest source package
> uploaded to Ubuntu? Does it include Changed-By? Is it a union of those?
> Or a union of all maintainers and changers over time?

I don't know what the best option is, but you might want to consider the
Uploaders field too. Although the MaintainerField specification forces a package
with Ubuntu changes to munge the Maintainer field, but not the Uploaders field,
so that could be a problem.