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

Maintainers and the Database



This mail message started out as a response to Marcus Brinkmann's
comment on the policy list:

> I think that [the multiple maintainer] issue can't be resolved
> properly ("we are stuck") without further input from all the other
> developers not participating on debian-policy.

I'm hardly a participant, but I do read it. This message is now mainly
about the database and only relates partly to the above. The real
questions are, IMO:

a) what is package ownership?

We need to know who put together a package, who to send bugs to and
who ping if the package needs to be updated. We need to know if a
package is orphaned (has no owner).

b) how well is this reflected in current practice (and policy)?
c) what changes are needed to improve the answer to b)?

I'm not touching these!

d) What about a database to handle some of this for us?

This is in progress and is what I ramble on about below (knowing
little about the existing db work).

*The Database*

It is important that the database reflect reality for it to be useful,
both in its design and in its content. This applies to all databases.
This is unexciting, but hopefully obvious.

  The Design

A database of Debian developers (package maintainers plus all those
helping with debian who do not actually emit .debs) is needed and in
preparation. Package ownership details are desired in the database.

Relational Databases 101 says you will need (at least) one relation
for the people and another for the packages. (It would be a bad design
to have an attribute "packages" which listed all their packages).

If each package has an attribute "owner" then there arises the problem
of what to put:

a) When there is no owner (orphaned). Answer: Easy, use NULL.

b) When there are multiple maintainers (maintainer group). Answer: say
   "oh dear", or enter only one of them (arguably incorrect), or
   create a fake maintainer which is actually a group (yuk yuk), or
   try and handle groups directly, in some moderately complicated
   fashion, OR:

If instead there is a separate relation for ownership linking people
and packages, then there is no problem with people having 0, 1 or more
packages or with packages having 0, 1 or more owners. Queries to list
orphaned packages, list a given person's packages, etc. are hardly any
more complicated than with the other design. Moreover, the data (and
schemas) are trivially convertible from the other design to this one.

Summary: it should not be a problem for the database what form of
"multiple maintainership" (if any) is eventually adopted.

* Could someone in the know say whether there is a separate ownership
* table? I am happy to give a hand with PostgreSQL hacking (I am in
* the process of setting up a (pg) db at work - a learning experience
* :-).

  The Content

Developer information should be at the control of the individuals and
I imagine this has been what most of the existing DB work has been on.

Package information is a different matter. One issue is what to do
when a package disappears for good, being deleted from the archive.
The corresponding entry in the database ought to be updated or deleted
to reflect this. Plenty of information can be extracted automatically
as each .deb arrives (including the _packager_ - via the PGP key).

Ownership information is a little more tricky (think NMUs, multiple
maintainer packages and orphaning) but it ought to be possible to
automate this to some extent.

Someone with ambition may want to do something to add summaries of
data in the bugs system.

* I am prepared to help with any of the miscellaneous scripting the
* above involves.

  DB Care

Once a design stabilises the db needs to be looked after in much the
same way that Guy (and helpers) look(s) after the archive. The web (or
whatever) interface is unlikely to be perfect initially and will need
maintainance.

  The "Maintainer:" field

This will probably be rather important in terms of generating data for
the db. It is supposed to be the canonical means of contact between
user and developer in relation to a given package. I know much less
about how this propagated and used by various things (bug db, bug
command, dinstall, dpkg-*). It is something you can mail (i.e., one or
more email addresses).

Whereas packages are nicely identified by their name. The same cannot
be said of developers and the "Maintainer:" field, at the moment. This
is unfortunate. Most email addresses found in the field correspond to
an entry in the PGP key ring and hence to real humans.

There are plenty of (technical) solutions to this problem and the with
luck a wider discussion of the "multiple maintainer" issue will fix
this as a consequence.

Enough rambling,
Giuliano Procida (Myxie)
-- 
mail: gpp10@cam.ac.uk / myxie@debian.org | public PGP key ID: 93898735
home: +44 1223 561237 / 547 Newmarket Road, Cambridge CB5 8PA, UK
work: +44 1223 332127 / Magdalene College, Cambridge CB3 0AG, UK
work: +44 1223 335333 / International Studies, Cambridge CB2 1QY, UK


--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: