| 1 |
[[!meta title="DEP-2: Debian Package Maintenance Hub"]]
|
| 2 |
|
| 3 |
Title: Debian Package Maintenance Hub
|
| 4 |
DEP: 2
|
| 5 |
State: DRAFT
|
| 6 |
Date: 2012-01-13
|
| 7 |
Drivers: Raphael Hertzog <hertzog@debian.org>
|
| 8 |
URL: http://dep.debian.net/deps/dep2
|
| 9 |
Abstract:
|
| 10 |
Debian maintainers rely on a multitude of services (DDPO, PTS,
|
| 11 |
DDPO-by-mail, BTS, etc), and information sources, in order to do
|
| 12 |
their job. The flow of information varies greatly from case to case.
|
| 13 |
.
|
| 14 |
This proposal is about creating a central infrastructure
|
| 15 |
that would consolidate several of those services and that would
|
| 16 |
standardize the information flow.
|
| 17 |
|
| 18 |
|
| 19 |
Rationale
|
| 20 |
---------
|
| 21 |
This new package maintenance infrastructure is needed:
|
| 22 |
|
| 23 |
* to fix long standing problems;
|
| 24 |
* to implement new features that will help us to ensure that all Debian
|
| 25 |
packages are well maintained;
|
| 26 |
* to be more pro-active and to detect problems sooner.
|
| 27 |
|
| 28 |
### Problems to solve
|
| 29 |
|
| 30 |
#### Maintainer vs Uploader
|
| 31 |
|
| 32 |
The flow of information is not the same depending on whether you're
|
| 33 |
listed in the Maintainer field (in which case most services mail you
|
| 34 |
directly) or not (in which case you're supposed to subscribe via the PTS
|
| 35 |
or via a dedicated mailing list). But the opposite is true as well, some
|
| 36 |
information is only available via the PTS and many maintainers have to
|
| 37 |
subscribe to the PTS while excluding almost everything just to get
|
| 38 |
the information they want.
|
| 39 |
|
| 40 |
See also [#507288](http://bugs.debian.org/507288) for some more
|
| 41 |
discussions on this topic.
|
| 42 |
|
| 43 |
This makes it very painful to change/switch the Maintainer field because
|
| 44 |
people have to update their PTS subscriptions accordingly.
|
| 45 |
|
| 46 |
#### Duplication of work / inconsistency between the DDPO and the PTS
|
| 47 |
|
| 48 |
The DDPO and the PTS are completely separate services. This leads to
|
| 49 |
duplication of work when a new information needs to be made available in
|
| 50 |
their respective interface. It can also lead to inconsistencies between
|
| 51 |
both services when bug occurs or when different choices are made.
|
| 52 |
|
| 53 |
#### Mailing lists as Maintainer
|
| 54 |
|
| 55 |
We often have mailing lists listed in the Maintainer field and it's not
|
| 56 |
clear who are the real package maintainers and how many of them there are.
|
| 57 |
The Uploaders field is often outdated, and/or is just a representation of
|
| 58 |
who worked last on the package instead of who feels responsible for the
|
| 59 |
package.
|
| 60 |
|
| 61 |
### Goals
|
| 62 |
|
| 63 |
#### Tracking commitments
|
| 64 |
|
| 65 |
A package can only be well maintained if it has at least one or more
|
| 66 |
committed maintainers. This new infrastructure should let us monitor
|
| 67 |
actions that prove or disprove the commitment of the persons who have
|
| 68 |
a relationship with the package. Contributors should also be able to
|
| 69 |
state explicitly the nature of their relationship with the package (lead
|
| 70 |
maintainer, co-maintainer, backup maintainer, follower/lurker, etc.).
|
| 71 |
|
| 72 |
Packages without (enough) committed maintainers can then be advertised as
|
| 73 |
needing help before it's too late and before the package suffered too
|
| 74 |
much. Maintainers who are failing to keep up with the commitments they set
|
| 75 |
for themselves can be automatically prodded.
|
| 76 |
|
| 77 |
#### Support alternate notification systems
|
| 78 |
|
| 79 |
Email is the only official media used to communicate information to
|
| 80 |
Debian package maintainers. If all the relevant mails are going through
|
| 81 |
a central service, it's possible to store those emails and to forward
|
| 82 |
the relevant information by other means (RSS, XMPP, IRC, etc.). Also
|
| 83 |
new maintainers can then have access to some historic information
|
| 84 |
that used to be private for no good reasons.
|
| 85 |
|
| 86 |
|
| 87 |
Design of the new infrastructure
|
| 88 |
--------------------------------
|
| 89 |
|
| 90 |
### Fixing the flow of information
|
| 91 |
|
| 92 |
In order to cleanly solve the problem of the information flow, and to get
|
| 93 |
rid of the hacks made everywhere to send a copy of the mails to the PTS,
|
| 94 |
packages would be (progressively) modified to indicate
|
| 95 |
“Maintainer: <source>@pkgmaint.debian.org” in their control file.
|
| 96 |
|
| 97 |
Until all packages have been converted, the PTS would forward copies of
|
| 98 |
the mails to ensure that the new infrastucture can still be used for all
|
| 99 |
packages (even those who have not been updated yet).
|
| 100 |
|
| 101 |
Using this intermediary address also solves the problem of maintainers who
|
| 102 |
orphan their packages and are still listed as maintainers in many released
|
| 103 |
packages.
|
| 104 |
|
| 105 |
### Replacing maintenance mailing lists
|
| 106 |
|
| 107 |
Packaging teams often separate the mailing list that gets the bug traffic and
|
| 108 |
other notifications from their main discussion mailing list. This new
|
| 109 |
infrastructure should entirely replace the former kind of mailing lists.
|
| 110 |
Anybody receiving notifications and information directed to the package
|
| 111 |
maintainer should get them via this new infrastructure.
|
| 112 |
|
| 113 |
It allows us to know how many people are notified for a given problem.
|
| 114 |
If nobody is notified, the package is effectively orphaned. A more
|
| 115 |
interesting case to detect is when several persons are being notified but
|
| 116 |
all of them are MIA or marked as being busy/on vacation.
|
| 117 |
|
| 118 |
Acronyms
|
| 119 |
--------
|
| 120 |
|
| 121 |
* DDPO: [Debian Developer's Packages Overview](http://qa.debian.org/developer.php)
|
| 122 |
* PTS: [Package Tracking System](http://packages.qa.debian.org)
|
| 123 |
* BTS: [Bug Tracking System](http://bugs.debian.org)
|
| 124 |
|
| 125 |
Changes
|
| 126 |
-------
|
| 127 |
|
| 128 |
* 2011-01-13: Initial draft by Raphaël Hertzog.
|
| 129 |
|
Parent Directory
| 
Revision Log