[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Best scheme for teams and Maintainer/Uploaders fields ?



On Mon, Jan 08, 2007 at 09:03:03AM +0100, Lucas Nussbaum wrote:
> I'm a member of the pkg-ruby-extras team. In this team, we use the
> following scheme for the Maintainer and Uploaders fields:
>   Maintainer: "main responsible person for the package" (ie best contact
>   point)
>   Uploaders: the team mailing list, + all the members of the team
>   (auto-generated using a cdbs rule)

In the OCaml team we do the following:

  Maintainer: the team mailing list
  Uploaders: all the members of the team

I actually want to change this policy so that Uploaders only list people
who "cares" for a given package inside the team. A reasonable definition
of "cares for" can be: have their name in the changelog of that package
at least one time or something such.

> This is not optimal:
> - this generates very long DDPO pages, with lots of packages people
>   don't care about:
>   http://qa.debian.org/developer.php?login=lucas@lucas-nussbaum.net

I do think this is an issue, but at a different level. The DDPO is
already able to distinguish packages in which you're listed as an
uploadeder, it shows them in blue. I think we need some more
fine-grained filtering, like the following two:
- please do not show me packages of which I'm just an uploaded
- please do not show me packages team-maintained (that's of course a bit
  more tricky, since it requires team-knowledge for DDPO, but I think
  this kind of information would be useful elsewhere for QA purposes)

> - it's difficult to keep track of who is caring for that package (hint:
>   QA, MIA, ...)

Uh? Why? Your maintainer field seems to address this issue. In our
scheme that's would be more a problem, but if the mailing list is
responsive it's enough. Think for example at the debian-release mailing
list: it's a list, but it's really responsive for all packages in the
archive. So IMO not being able to identify a single person is not
necessarily an indicator of unresponsiveness for a given package.

> Shouldn't this be documented somewhere (developer's reference ?) ?

I think we really need to document a best practice for this, thanks for
bringing it up.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

Attachment: signature.asc
Description: Digital signature


Reply to: