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

Proposal: a more general and flexible appoach of packages.


On Thu, 10 Dec 1998, Martin Schulze wrote:

> packages.debian.org@packages.debian.org should be a valid address.  Would
> that be sufficient for you?

"packages.debian.org@packages.debian.org"  ?


With an email address like that, there must be a great idea behind it :-)

Seriously, packages@packages.debian.org, secretary@debian.org and
whatever else could reasonable be expected to be considered "intuitive",
"logical" and "sensible" by anyone trying to find the right guy to write
to should also know how to deal with administrative requests re. the
packages lists.  "packages.debian.org@packages.debian.org" is a real gem
though, I must admit and I love it :-)

I would like to extend the current proposal more generally with regard to 
the notion of a "package", but first I would like to write down some of
my opinions of how the packages.debian.org lists should be implemented:

1 - for every package "foo", there should automatically be a mailinglist
  foo@packages.debian.org.  The maintainer of "foo" must always be on the
  mailinglist, but others might subscribe or be subscribed (see below) as

2 - the foo@packages list should be the primary contact address for all
  things related to the "foo" package, e.g all bugreports should be
  forwarded to this list.

3 - the "main" maintainer of "foo" and the packages.debian.org lists
  maintainer should have administrative powers for the foo@packages list.

4 - preferrably, packages.debian.org lists should be open to public
  subscription, optionally with a system defaulting read-only access, 
  with more rights grantable by the list administrator. 

5 - for every virtual package "bar", there should equally be a
  bar@packages list.  The joint maintainers of all real packages providing
  a virtual package "bar" should agree on an administrator.  

IMHO ideally, policy should state that more generally, a virtual package
needs to have a maintainer, appointed or chosen from the group of
maintainers of all real packages providing the virtual package.  Apart
from the intrinsic benefits of symmetry and clarity, this would
particularly obviate the need to make a special case for rule 5, by
folding it back into rule 1. 

Moreover, "special-interest packages"  (or focus groups) could be
formalized and get a baz@packages list. Without any package actually
providing "baz," a lot of packages could be involved with or affected by
"baz."  Think "xfree," "perl," python," "webserver," "emacs" or "base" 
instead of "baz"  and it makes a lot of practical sense to do this. 

Again, a central responsible person should be appointed (chosen.)  Again,
the benefits of the more generalised and standardised speak for
themselves:  more standardisation and symmetry, no need to spam -devel
with very detailed and topical discussions, better addressing of
responsibilities not by enforcement, but by creating clarity and an
infrastructure for focused debate.

Briefly returning back to the initial issue of packages.debian.org lists:

By rule 1, we'll have an intuitive contact address for each package in the

By rule 2, it will also be a guaranteed address.  

By rule 3 and 4, the individual maintainer is free to use "his" list for
whatever style of development he likes (without having to buy into the
particularities of whatever MTA.)

Another great benefit of this scheme is that when a maintainer goes AWOL,
the project secretary (or his delegate for maintainer maintenance) can
easily reset the main maintainer [subscription] address and best of all,
there will be no history problems, as foo@packages will always point to
the current maintainer of package "foo."



Reply to: