/[dep]/web/deps/dep2.mdwn

Diff of /web/deps/dep2.mdwn

Parent Directory | Revision Log | View Patch Patch

-revision 244 by hertzog,
Fri Jan 13 15:09:50 2012 UTC
+revision 250 by hertzog,
Sat Jan 28 15:27:31 2012 UTC
 Line 3
      Title: Debian Package Maintenance Hub
      DEP: 2
      State: DRAFT
-     Date: 2011-01-13
+     Date: 2012-01-13
      Drivers: Raphael Hertzog <hertzog@debian.org>
      URL: http://dep.debian.net/deps/dep2
      Abstract:
 Line 21 
 Rationale
  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
+  * to provide a clean base to implement new features:
-    packages are well maintained;
+    * that will help maintainers do a better job;
-  * to be more pro-active and to detect problems sooner.
+    * 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
-Line 41 
 See also [#507288](http://bugs.debian.or
+Line 43 
 See also [#507288](http://bugs.debian.or
  discussions on this topic.
  This makes it very painful to change/switch the Maintainer field because
  people have to update their PTS subscriptions accordingly.
  #### Duplication of work / inconsistency between the DDPO and the PTS
-Line 60 
 package.
+Line 62 
 package.
  ### Goals
- #### Tracking commitments
+ #### Provide a working replacement for DDPO/PTS
- A package can only be well maintained if it has at least one or more
+ Since the service aims to merge the DDPO and the PTS, it must be a working
- committed maintainers. This new infrastructure should let us monitor
+ replacement of both services and its set of features must englobe the
- actions that prove or disprove the commitment of the persons who have
+ features of the actual services.
- 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.
  #### Support alternate notification systems
-Line 83 
 the relevant information by other means
+Line 77 
 the relevant information by other means
  new maintainers can then have access to some historic information
  that used to be private for no good reasons.
+ #### Enable new interactions with maintainers
- Design of the new infrastructure
+ 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
+ other notifications from their main discussion mailing list. This new
+ infrastructure should entirely replace the former kind of mailing lists.
+ Anybody receiving notifications and information directed to the package
+ maintainer should get them via this new infrastructure.
+ 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 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
+ Since the infrastructure already stores the information about who is
+ maintaining what, it only makes sense to extend it to provide the
+ list of orphaned packages (i.e. packages without maintainers).
+ RFH should be replaced by a system where the help request is better
+ formalized so that we can better direct new contributors in places
+ where their skills would be well used. Instead of just requesting
+ help, you could request:
+ - a new maintainer (to replace you, i.e. RFA)
+ - a supplementary co-maintainer
+ - a bug triager
+ - a C/Python/Perl/… programmer (you should be able to choose the programming
+   language)
+ Each request also documents whether there's an associated offer of
+ "mentorship" associated to the help request. Of course, there would
+ also be a free form description to give more details about what's
+ expected.
+ #### Replace the LowThresholdNmu list
+ The [LowThresholdNmu](http://wiki.debian.org/LowThresholdNmu) wiki page
+ 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.
+ High-level design of the new infrastructure
+ -------------------------------------------
  ### Fixing the flow of information
-Line 102 
 Using this intermediary address also sol
+Line 169 
 Using this intermediary address also sol
  orphan their packages and are still listed as maintainers in many released
  packages.
- ### Replacing maintenance mailing lists
+ ### Leveraging UDD
- Packaging teams often separate the mailing list that gets the bug traffic and
- other notifications from their main discussion mailing list. This new
- infrastructure should entirely replace the former kind of mailing lists.
- Anybody receiving notifications and information directed to the package
- maintainer should get them via this new infrastructure.
- 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.
+ 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, the diversity
+ of the tools and the fact that some are not widely known (e.g. XSLT)
+ seriously limit the set of contributors who are able to hack on all the
+ parts of the infrastructure.
+ With a modern framework for web development, we enlarge the set of people
+ who are able to help us develop and maintain this infrastructure. It also
+ offers us a proper separation between presentation and code, so that it's
+ easier to let web designers integrate this service with the general
+ look&feel of the various Debian websites. On top of this, we get a fully
+ internationalized website for free.
+ ### 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)
-  * PTS: [Bug Tracking System](http://bugs.debian.org)
+  * BTS: [Bug Tracking System](http://bugs.debian.org)
+  * UDD: [Ultimate Debian Database](http://udd.debian.org)
+  * DD: Debian Developer
+  * WNPP: [Work Needing and Prospective Packages](http://www.debian.org/devel/wnpp/)
+  * RFH: Request For Help
+  * RFA: Request For Adoption
+  * O: Orphaned
+  * NMU: Non-Maintainer Upload
  Changes
  -------
  * 2011-01-13: Initial draft by Raphaël Hertzog.
+ * 2011-01-28: Integrate feedback from debian-qa@lists.debian.org.

 Legend:



Removed from v.244
 


changed lines


 
Added in v.250
 Legend:



Removed from v.244
 


changed lines


 
Added in v.250
-Removed from v.244
+Added in v.250

	ViewVC Help
Powered by ViewVC 1.1.5