Hi,
Trying to solve that by (ab)using the Uploader field is the wrong approach, because it singles out individual members of the team as "the persons responsible for the package". That may not reflect the way the team actually works, goes against the very concept of team-maintainership, and doesn't actually solve the problem, because if a team member goes MIA who wasn't listed as uploader, this package wouldn't appear in the "reliable and complete list" that you're aiming at.
IMHO, that's how teams *should* work: For every package, someone (at least one person) is listed as the responsible person.
I am currently in this very situation with some of my team-maintained packages. I am listed as the Uploader (the only one), but want to get rid of these packages. What I did is ask in the team (either on the mailing lsit or directly the people who are also lsited in recent changelog entries) whether they want to take over that role. I will then update the Uploaders on all packages where I find someone new, and orphan all packages where I don't.
And I think while it's a bit effortful, it's absolutely the right way.I don't think it's against team maintenance. The difference between Uplaoders and Maintainers is the nuance of responsibility: If I team-maintain a package, I agree that everyone else in the time may at any time touch my package, as long as they do in accordance with any team policies. I still remain responsible, and if I don't agree with how the team helps maintaining the package and can't find consensus, I can either move it out of the team, or move myself out of the team.
The right solution is to have a canonical place within the project where the list of members of every team is stored and kept up-to-date. It is definitely not duplicating that information in every package. I don't know whether that already exists.
How should that work?It would require all teams to use a central mailing list infrastructure as well. tracker does have tools for maintaining semi-official team lists and mailing lists, but not everyone uses it, and there is no technical way to determine whether a package is team-maintained or not by looking at Maintainers. We'd either need a new field in d/control to encode that fact, or prescribe a unique e-mail domain for team mailing lists.
In conclusion, I think the Uplaoders field right now works exactly as I think it should.
-nik
OpenPGP_signature.asc
Description: OpenPGP digital signature

