[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ next ]


A mechanism for updating Debian Policy documents
Chapter 1 - Introduction, and Administrivia


This document documents the current practice followed in updating Debian Policy documents. This mechanism has been designed for dealing with policy changes that are light weight and can be decided upon within the policy group, by near consensus. In most day-to-day cases, the Policy group should and must be able to conduct Policy discussions and amendments without the intervention of the Technical Committee or other Constitutional issues. Only in cases of extreme dispute (formal objections) should the intervention of Constitutional bodies come into play. In any other situation, the Policy group should be able to conduct business unfettered. A consequence of this goal is that formal objections should not be used lightly, else this mechanism shall be ineffective.

It should be noted that the team responsible for the task of updating policy does not act as author or editor of Policy itself, that is the task of the Debian Policy mailing list.

In the following, the term developer refers to registered Debian developers.


1.1 Guidelines for policy change proposals

Policy does not document all existing practice. It only incorporates a minimal ruleset that is required for systems integration (usually selecting one branch from several equally viable technical options). It is not a best practices document.

Policy changes under this procedure also should almost never (unless directed by the tech-ctte, and perhaps the DPL) cause a change that would make a significant chunk of packages instantly buggy; for such changes, it is better to implement a gradual transition plan, allowing for partial upgrades (and perhaps using release goals as motivators). Part of the rationale for this is common sense; a global change, in the past, has taken time, and having either a large number of RC bugs, or ignoring a large number of bugs that would otherwise be RC seems silly; and, anyway, there are concerns that the policy group does not really have the power to change policy drastically. This is the basis of the policy shall not be used as a stick to beat developers with.

Nor does policy always document only existing practices. What that oft misquoted statement refers to was a part of was a larger thesis that is meant to suggest that policy is not the place for testing out design; if a complicated technical proposal is to be made into policy, it should be independently implemented, have all the kinks worked out, and then have that working model be implemented as policy. Having to change policy back and forth while a design is being worked out needs be avoided.


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ next ]


A mechanism for updating Debian Policy documents

$Revision: 1.7 $

Manoj Srivastava srivasta@debian.org