On Fri, Aug 04, 2017 at 12:37:53PM +0300, Adrian Bunk wrote: > > As an example, we do have teams that define in their policy the > semantics for "person in Maintainer, team in Uploaders".
That should be changed. Its a perfect way to exclude "Uploaders" from beeing informed about issues with a package. > It is interesting how you manage to argue both based on a very specific > definition of teams you have in mind, and based on declaring that all > this is not well-defined and that we neither can nor want to define it. > > What is needed is a machine-readable mapping between teams and their members. +1 > Mandatory Uploaders gives a good-enough approximation of that. I admit that at least one Uploader should be mandatory if Maintainer is not a person. > An alternative option of maintaining machine-readable information > about team member in a different place outside the packages would > fix the problem of losing information about team membership. What place would you suggest? If I would like to know all members of a team I would do an UDD query for all packages maintained by the team (mailing list address) and check the list of Uploaders mentioned of all those packages. May be that's a biased view that works in those teams I'm a member of. > Or the low-change option of documenting that the already used way of > autogenerating the Uploaders list based on information stored in one > core package of the team is a valid option - this allows teams with many > packages to get rid of the problem of having to update this information > manually in every single package. I'm convinced that manual updating of team membership will not work. Its the reason why I started team analysis stats 9 years ago since I just was not able to tell who is a member of Debian Med and who is not. Kind regards Andreas. -- http://fam-tille.de