r251 - /web/deps/dep2.mdwn

Sat Jan 28 15:27:36 UTC 2012

Author: hertzog
Date: Sat Jan 28 15:27:36 2012
New Revision: 251

URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=251
Log:
DEP-2: Re-order the goals

Modified:
    web/deps/dep2.mdwn

Modified: web/deps/dep2.mdwn
URL: http://svn.debian.org/wsvn/dep/web/deps/dep2.mdwn?rev=251&op=diff
==============================================================================

--- web/deps/dep2.mdwn (original)
+++ web/deps/dep2.mdwn Sat Jan 28 15:27:36 2012
@@ -68,35 +68,6 @@
 replacement of both services and its set of features must englobe the
 features of the actual services.
 
-#### Support alternate notification systems
-
-Email is the only official media used to communicate information to
-Debian package maintainers. If all the relevant mails are going through
-a central service, it's possible to store those emails and to forward
-the relevant information by other means (RSS, XMPP, IRC, etc.). Also
-new maintainers can then have access to some historic information
-that used to be private for no good reasons.
-
-#### Enable new interactions with maintainers
-
-The central role of this new "communication infrastructure" makes it
-possible to design new interactions with maintainers. Instead of being
-only a source of information, the infrastructure could be used to query
-package maintainers and/or let them provide supplementary information.
-
-This could be used to improve the MIA tracking process.
-
-This infrastructure would also be a more natural place to store the
-"available for Debian work" boolean flag ("vacation") that's currently
-never used because it's buried in db.debian.org and that it's not
-practical to update it.
-
-This infrastructure could also be used to let maintainers document the
-responsibilities that they have agreed to endorse, and describe the
-associated commitments. That way it would be easier to detect packages
-that cannot be well maintained because the set of maintainers do not cover
-all the tasks that must be assumed to have a properly maintained package.
-
 #### Replace maintenance mailing lists
 
 Packaging teams often separate the mailing list that gets the bug traffic and
@@ -110,17 +81,6 @@
 interesting case to detect is when several persons are being notified but
 all of them are MIA or marked as not being available for Debian (busy/in
 vacation).
-
-#### Provide new services to packaging teams
-
-Given that this infrastructure would have native support for packaging
-teams, it would also be a good place to offer some standardized services
-for them.
-
-For example, one of the central tool for teams are their VCS and it can be
-useful for teams to be able to monitor the state of their package in the
-VCS. The [PET](http://pet.alioth.debian.org/) tool could be adapted,
-integrated and made available to all teams by default.
 
 #### Replace WNPP's RFH, RFA, O
 
@@ -149,6 +109,46 @@
 is a hack to let people know when NMU are welcome and not frowned
 upon. This information should be properly stored in the database
 and it should be associated to each package.
+
+#### Enable new interactions with maintainers
+
+The central role of this new "communication infrastructure" makes it
+possible to design new interactions with maintainers. Instead of being
+only a source of information, the infrastructure could be used to query
+package maintainers and/or let them provide supplementary information.
+
+This could be used to improve the MIA tracking process.
+
+This infrastructure would also be a more natural place to store the
+"available for Debian work" boolean flag ("vacation") that's currently
+never used because it's buried in db.debian.org and that it's not
+practical to update it.
+
+This infrastructure could also be used to let maintainers document the
+responsibilities that they have agreed to endorse, and describe the
+associated commitments. That way it would be easier to detect packages
+that cannot be well maintained because the set of maintainers do not cover
+all the tasks that must be assumed to have a properly maintained package.
+
+#### Provide new services to packaging teams
+
+Given that this infrastructure would have native support for packaging
+teams, it would also be a good place to offer some standardized services
+for them.
+
+For example, one of the central tool for teams are their VCS and it can be
+useful for teams to be able to monitor the state of their package in the
+VCS. The [PET](http://pet.alioth.debian.org/) tool could be adapted,
+integrated and made available to all teams by default.
+
+#### Support alternate notification systems
+
+Email is the only official media used to communicate information to
+Debian package maintainers. If all the relevant mails are going through
+a central service, it's possible to store those emails and to forward
+the relevant information by other means (RSS, XMPP, IRC, etc.). Also
+new maintainers can then have access to some historic information
+that used to be private for no good reasons.
 
 
 High-level design of the new infrastructure


