r249 - /web/deps/dep2.mdwn
hertzog at users.alioth.debian.org
hertzog at users.alioth.debian.org
Thu Jan 26 21:48:59 UTC 2012
Author: hertzog
Date: Thu Jan 26 21:48:59 2012
New Revision: 249
URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=249
Log:
DEP-2: continue work on the design
Modified:
web/deps/dep2.mdwn
Modified: web/deps/dep2.mdwn
URL: http://svn.debian.org/wsvn/dep/web/deps/dep2.mdwn?rev=249&op=diff
==============================================================================
--- web/deps/dep2.mdwn (original)
+++ web/deps/dep2.mdwn Thu Jan 26 21:48:59 2012
@@ -21,9 +21,11 @@
This new package maintenance infrastructure is needed:
* to fix long standing problems;
- * to implement new features that will help us to ensure that all Debian
- packages are well maintained;
- * to be more pro-active and to detect problems sooner.
+ * to provide a clean base to implement new features:
+ * that will help maintainers do a better job;
+ * that will help packaging teams to organize themselves;
+ * that will help the QA team to ensure that all Debian packages are
+ well maintained.
### Problems to solve
@@ -60,19 +62,11 @@
### Goals
-#### Tracking commitments
-
-A package can only be well maintained if it has at least one or more
-committed maintainers. This new infrastructure should let us monitor
-actions that prove or disprove the commitment of the persons who have
-a relationship with the package. Contributors should also be able to
-state explicitly the nature of their relationship with the package (lead
-maintainer, co-maintainer, backup maintainer, follower/lurker, etc.).
-
-Packages without (enough) committed maintainers can then be advertised as
-needing help before it's too late and before the package suffered too
-much. Maintainers who are failing to keep up with the commitments they set
-for themselves can be automatically prodded.
+#### Provide a working replacement for DDPO/PTS
+
+Since the service aims to merge the DDPO and the PTS, it must be a working
+replacement of both services and its set of features must englobe the
+features of the actual services.
#### Support alternate notification systems
@@ -83,26 +77,27 @@
new maintainers can then have access to some historic information
that used to be private for no good reasons.
-
-Design of the new infrastructure
---------------------------------
-
-### Fixing the flow of information
-
-In order to cleanly solve the problem of the information flow, and to get
-rid of the hacks made everywhere to send a copy of the mails to the PTS,
-packages would be (progressively) modified to indicate
-“Maintainer: <source>@pkgmaint.debian.org†in their control file.
-
-Until all packages have been converted, the PTS would forward copies of
-the mails to ensure that the new infrastucture can still be used for all
-packages (even those who have not been updated yet).
-
-Using this intermediary address also solves the problem of maintainers who
-orphan their packages and are still listed as maintainers in many released
-packages.
-
-### Replacing maintenance mailing lists
+#### 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.
+
+#### Replacing maintenance mailing lists
Packaging teams often separate the mailing list that gets the bug traffic and
other notifications from their main discussion mailing list. This new
@@ -113,14 +108,95 @@
It allows us to know how many people are notified for a given problem.
If nobody is notified, the package is effectively orphaned. A more
interesting case to detect is when several persons are being notified but
-all of them are MIA or marked as being busy/on vacation.
+all of them are MIA or marked as not being available for Debian (busy/in
+vacation).
+
+
+High-level design of the new infrastructure
+-------------------------------------------
+
+### Fixing the flow of information
+
+In order to cleanly solve the problem of the information flow, and to get
+rid of the hacks made everywhere to send a copy of the mails to the PTS,
+packages would be (progressively) modified to indicate
+“Maintainer: <source>@pkgmaint.debian.org†in their control file.
+
+Until all packages have been converted, the PTS would forward copies of
+the mails to ensure that the new infrastucture can still be used for all
+packages (even those who have not been updated yet).
+
+Using this intermediary address also solves the problem of maintainers who
+orphan their packages and are still listed as maintainers in many released
+packages.
+
+### Leveraging UDD
+
+At least the PTS has been parsing Sources/Packages files by itself, as
+well as a bunch of other source of information. But many of the most
+recent developments have piggy-backed on UDD to retrieve the information
+needed, leaving to UDD the responsibility of bringing all the information
+in a single place.
+
+This principle should be generalized to avoid duplication of work and to
+make sure that all the important information are available in UDD.
+
+But we must make sure that UDD won't become a bottleneck. Either because
+we have a local (live?) replicate of the database, or because we have
+ensured that our usage of UDD is limited to batch tasks that are not
+on the critical path for all the real-time user requests.
+
+### Using a modern framework for web development
+
+DDPO is implemented in PHP. The PTS uses a mix of Perl, Python, XSLT and
+shell scripts. While both works very well and are reliable, we can do much
+better by using a modern framework for web development (starting with
+internationalization of the web interface).
+
+### API for data export
+
+If the infrastructure is going to have a central role, there will be
+requests to extract data out of the system. We should cater for this by
+providing a public API (over HTTP) allowing to retrieve all the (public)
+information in some standardized manner.
+
+JSON seems to be a good option for data export. It allows other services
+to reuse information from the DPMH, and it makes it easy for various
+web services to retrieve the information dynamically via Javascript.
+
+### Native support of packaging teams
+
+Any Debian Developer must be able to create a "packaging team" in the
+system. Each packaging team has a set of packages that it maintains (or
+keeps an eye on). Anyone can "subscribe" to the team and gets (by default)
+all correspondance of all packages associated to that team.
+
+The team subscription can be tuned (much like the current PTS subscription)
+to receive only a subset of the usual mails. A direct package subscription would
+take precedence over a team subscription, thus allowing the user to
+exclude some packages from its team subscription (or get more info for
+some specific packages where they are particularly interested).
+
+
+Implementation details
+----------------------
+
+Questions:
+
+ * How do we store emails? For how long? (we store all mails except the BTS mails)
+ * What language and web framework? (buxy's default choice: Python & Django)
+ * How do we authenticate users? And for DD super-powers?
+ * [To be completed]
Acronyms
--------
+ * DPMH: Debian Package Maintenance Hub (this project)
* DDPO: [Debian Developer's Packages Overview](http://qa.debian.org/developer.php)
* PTS: [Package Tracking System](http://packages.qa.debian.org)
* BTS: [Bug Tracking System](http://bugs.debian.org)
+ * UDD: [Ultimate Debian Database](http://udd.debian.org)
+ * DD: Debian Developer
Changes
-------
More information about the dep-commits
mailing list