*.ps
*.ps.gz
*.tpt
-*.txt
*.txt.gz
menu-policy.sgml: version.ent
mime-policy.sgml: version.ent
+ifneq (,$(strip $(HAVE_ORG_EMACS)))
+%.txt: %.org
+ $(EMACS) --batch -Q -l ./README-css.el -l org --visit $^ \
+ --funcall org-export-as-ascii >/dev/null 2>&1
+%.html: %.org
+ $(EMACS) --batch -Q -l ./README-css.el -l org --visit $^ \
+ --funcall org-export-as-html-batch >/dev/null 2>&1
+endif
+
%.validate: %
nsgmls -wall -gues $<
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"
+lang="en" xml:lang="en">
+<head>
+<div style="text-align:right;font-size:70%;white-space:nowrap;">
+ <a accesskey="h" href="http://www.debian.org/"> UP </a>
+ |
+ <a accesskey="H" href="http://wiki.debian.org/Teams/Policy"> HOME </a>
+</div>
+
+<title>Debian Policy changes process</title>
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
+<meta name="generator" content="Org-mode"/>
+<meta name="generated" content="2009-09-13 16:13:52 CDT"/>
+<meta name="author" content="Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava"/>
+<meta name="description" content=""/>
+<meta name="keywords" content=""/>
+
+<style type="text/css">
+ html { font-family: Times, serif; font-size: 12pt; }
+ .title { text-align: center; }
+ p.verse { margin-left: 3% }
+ pre {
+ border: 1pt solid #AEBDCC;
+ color: #000000;
+ background-color: LightSlateGray;
+ padding: 5pt;
+ font-family: "Courier New", courier, monospace;
+ font-size: 90%;
+ overflow:auto;
+ }
+ dt { font-weight: bold; }
+ div.figure { padding: 0.5em; }
+ div.figure p { text-align: center; }
+ .linenr { font-size:smaller }
+ .code-highlighted {background-color:#ffff00;}
+ .org-info-js_info-navigation { border-style:none; }
+ #org-info-js_console-label { font-size:10px; font-weight:bold;
+ white-space:nowrap; }
+ .org-info-js_search-highlight {background-color:#ffff00; color:#000000;
+ font-weight:bold; }
+
+ body {
+ color: DarkSlateGrey;
+ background-color: gainsboro;
+ font-family: Palatino, "Palatino Linotype", "Hoefler Text", "Times New Roman", Times, Georgia, Utopia, serif;
+ }
+ .org-agenda-date { color: #87cefa; }
+ .org-agenda-structure { color: #87cefa; }
+ .org-scheduled { color: #98fb98; }
+ .org-scheduled-previously { color: #ff7f24; }
+ .org-scheduled-today { color: #98fb98; }
+ .org-tag { font-weight: bold; }
+ .org-todo {
+ color: #ffc0cb;
+ font-weight: bold;
+ }
+
+ a {
+ color: inherit;
+ background-color: inherit;
+ font: inherit;
+ text-decoration: inherit;
+ }
+ a:hover { text-decoration: underline; }
+ .todo { font-weight:bold; }
+ .done { font-weight:bold; }
+ .TODO { color:red; }
+ .WAITING { color:orange; }
+ .DONE { color:green; }
+ .timestamp { color: grey }
+ .timestamp-kwd { color: CadetBlue }
+ .tag { background-color:lightblue; font-weight:normal }
+ .target { background-color: lavender; }
+table {
+ border-collapse: collapse; /*separate; */
+ border: outset 3pt;
+ border-spacing: 0pt;
+ /* border-spacing: 5pt; */
+ }
+table td { vertical-align: top; border: 1px solid; }
+table th { vertical-align: top; border: 2px solid; }
+</style>
+<script ="text/javascript" language="JavaScript" src="/styles/org-info.js"></script>
+<script type="text/javascript" language="JavaScript">
+/* <![CDATA[ */
+org_html_manager.set("LOCAL_TOC", 0);
+org_html_manager.set("VIEW_BUTTONS", 1);
+org_html_manager.set("VIEW", "info");
+org_html_manager.set("TOC", 1);
+org_html_manager.set("MOUSE_HINT", "underline"); // could be a background-color like #eeeeee
+org_html_manager.setup ();
+/* ]]> */
+</script>
+
+<script type="text/javascript">
+<!--/*--><![CDATA[/*><!--*/
+ function CodeHighlightOn(elem, id)
+ {
+ var target = document.getElementById(id);
+ if(null != target) {
+ elem.cacheClassElem = elem.className;
+ elem.cacheClassTarget = target.className;
+ target.className = "code-highlighted";
+ elem.className = "code-highlighted";
+ }
+ }
+ function CodeHighlightOff(elem, id)
+ {
+ var target = document.getElementById(id);
+ if(elem.cacheClassElem)
+ elem.className = elem.cacheClassElem;
+ if(elem.cacheClassTarget)
+ target.className = elem.cacheClassTarget;
+ }
+/*]]>*///-->
+</script>
+</head>
+<body>
+<div id="content">
+<h1 class="title">Debian Policy changes process</h1>
+
+
+<div id="outline-container-1" class="outline-2">
+<h2 id="sec-1">Change Goals </h2>
+<div class="outline-text-2" id="text-1">
+
+
+<ul>
+<li>
+The change should be technically correct, and consistent with the
+rest of the policy document. This means no legislating the value of
+π. This also means that the proposed solution be known to work;
+iterative design processes do not belong in policy.
+</li>
+<li>
+The change should not be too disruptive; if very many packages
+become instantly buggy, then instead there should be a transition
+plan. Exceptions should be rare (only if the current state is really
+untenable), and probably blessed by the TC.
+</li>
+<li>
+The change has to be reviewed in depth, in the open, where any one
+may contribute; a publicly accessible, archived, open mailing list.
+</li>
+<li>
+Proposal should be addressed in a timely fashion.
+</li>
+<li>
+Any domain experts should be consulted, since not every policy
+mailing list subscriber is an expert on everything, including policy
+maintainers.
+</li>
+<li>
+The goal is rough consensus on the change, which should not be hard
+if the matter is technical. Technical issues where there is no
+agreement should be referred to the TC; non-technical issues should
+be referred to the whole developer body, and perhaps general
+resolutions lie down that path.
+</li>
+<li>
+Package maintainers whose packages may be impacted should have
+access to policy change proposals, even if they do not subscribe to
+policy mailing lists (policy gazette?).
+
+</li>
+</ul>
+</div>
+
+</div>
+
+<div id="outline-container-2" class="outline-2">
+<h2 id="sec-2">Current Process </h2>
+<div class="outline-text-2" id="text-2">
+
+
+<p>
+Each suggested change goes through different states. These states are
+denoted through either usertags of the
+<a href="mailto:debian-policy@packages.debian.org">debian-policy@packages.debian.org</a> user or, for patch, pending, and
+wontfix, regular tags.
+</p>
+<p>
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done">Current list of bugs</a>
+</p>
+<p>
+The Policy delegates are responsible for managing the tags on bugs and
+will update tags as new bugs are submitted or as activity happens on
+bugs. All Debian Developers should feel free to add the seconded tag
+as described below. Other tags should be changed with the coordination
+of the Policy Team.
+</p>
+
+</div>
+
+<div id="outline-container-2.1" class="outline-3">
+<h3 id="sec-2.1">State A: Issue raised </h3>
+<div class="outline-text-3" id="text-2.1">
+
+
+<p>
+Detect need, like gaps/flaws in current policy, or a new rule should
+be added. Any user or developer may start this step. There is a
+decision point here, not all issues are in scope of policy.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&tag=issue">TAG: issue</a>
+</p>
+<p>
+What needs to happen next: If this is in scope for Policy, discuss the
+issue and possible solutions, moving to the discussion tag, or if the
+matter is sufficiently clear, go directly to a proposal for how to
+address it, moving to the proposal tag. If this is not in scope for
+Policy, close the bug.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.2" class="outline-3">
+<h3 id="sec-2.2">State B: Discussion </h3>
+<div class="outline-text-3" id="text-2.2">
+
+
+<p>
+Discuss remedy. Alternate proposals. Discussion guided by
+delegates. There should be a clear time limit to this stage, but as
+yet we have not set one.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=discussion">TAG: discussion</a>
+</p>
+<p>
+What needs to happen next: Reach a conclusion and consensus in the
+discussion and make a final proposal for what should be changed (if
+anything), moving to the proposal tag.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.3" class="outline-3">
+<h3 id="sec-2.3">State D: Proposal </h3>
+<div class="outline-text-3" id="text-2.3">
+
+
+<p>
+A final proposal has emerged from the discussion, and there is a rough
+consensus on how to proceed to resolve the issue.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=proposal">TAG: proposal</a>
+</p>
+<p>
+What needs to happen next: Provided that the rough consensus persists,
+develop a patch against the current Policy document with specific
+wording of the change. Often this is done in conjunction with the
+proposal, in which case one may skip this step and move directly to
+patch tag.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.4" class="outline-3">
+<h3 id="sec-2.4">State E: Wording proposed </h3>
+<div class="outline-text-3" id="text-2.4">
+
+
+<p>
+A patch against the Policy document reflecting the consensus has been
+created and is waiting for formal seconds. The standard patch tag is
+used for this state, since it's essentially equivalent to the standard
+meaning of that tag.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch">TAG: patch</a>
+</p>
+<p>
+What needs to happen next: The proposal needs to be reviewed and
+seconded. Any Debian developer who agrees with the change and the
+conclusion of rough consensus from the discussion should say so in the
+bug log by seconding the proposal.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.5" class="outline-3">
+<h3 id="sec-2.5">State F: Seconded </h3>
+<div class="outline-text-3" id="text-2.5">
+
+
+<p>
+The proposal is signed off on by N Debian Developers. To start with,
+we're going with N=3, meaning that if three Debian Developers agree,
+not just with the proposal but with the conclusion that it reflects
+consensus and addresses the original issue – it is considered
+eligible for inclusion in the next version of Policy. Since Policy is
+partly a technical project governance method, one must be a Debian
+Developer to formally second, although review and discussion is
+welcome from anyone. Once this tag has been applied, the bug is
+waiting for a Policy team member to apply the patch to the package
+repository.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=seconded">TAG: seconded</a>
+</p>
+<p>
+What needs to happen next: A Policy maintainer does the final review
+and confirmation, and then applies the patch for the next Policy
+release.
+</p>
+<p>
+This tag is not used very much because normally a Policy maintainer
+applies the patch and moves the proposal to the next state once enough
+seconds are reached.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.6" class="outline-3">
+<h3 id="sec-2.6">State G: Accepted </h3>
+<div class="outline-text-3" id="text-2.6">
+
+
+<p>
+Change accepted, will be in next upload. The standard pending tag is
+used for this state since it matches the regular meaning of
+pending.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=pending">TAG: pending</a>
+</p>
+<p>
+What needs to happen next: The bug is now in the waiting queue for the
+next Policy release, and there's nothing left to do except for upload
+a new version of Policy.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.7" class="outline-3">
+<h3 id="sec-2.7">State H: Reject </h3>
+<div class="outline-text-3" id="text-2.7">
+
+
+<p>
+Rejected proposals. The standard wontfix is used for this
+state. Normally, bugs in this state will not remain open; instead, a
+Policy team member will close them with an explanation. The submitter
+may then appeal to the tech-ctte if they so desire. Alternately,
+issues appealed to the tech-ctte may remain open with this tag while
+that appeal proceeds.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=rejected">TAG: wontfix</a>
+</p>
+<p>
+We may use one of the following tags here, but to date we have only
+used dubious and ctte. It's not clear whether we need more tags for
+this tage.
+</p>
+<dl>
+<dt><b>dubious</b></dt><dd>
+Not a policy matter
+</dd>
+<dt><b>ctte</b></dt><dd>
+Referred to the Technical Committee (tech-ctte)
+</dd>
+<dt><b>devel</b></dt><dd>
+Referred to the developer body
+</dd>
+<dt><b>delegate</b></dt><dd>
+Rejected by a Policy delegate
+</dd>
+<dt><b>obsolete</b></dt><dd>
+The proposal timed out without a conclusion
+
+</dd>
+</dl>
+
+<p>What needs to happen next: The bug should be closed once a final
+resolution is reached, or retagged to an appropriate state if that
+final resolution reverses the decision to reject the proposal.
+</p>
+</div>
+</div>
+
+</div>
+
+<div id="outline-container-3" class="outline-2">
+<h2 id="sec-3">Other Tags </h2>
+<div class="outline-text-2" id="text-3">
+
+
+<p>
+All Policy bugs are additionally categorized by class of bug.
+</p>
+<p>
+The normative tag is used for bugs that make normative changes to
+Policy, meaning that the dictates of Policy will change in some
+fashion as part of the resolution of the bug if the proposal is
+accepted. The full process is followed for such bugs.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=normative">TAG: normative</a>
+</p>
+<p>
+The informative tag is used for bugs about wording issues, typos,
+informative footnotes, or other changes that do not affect the formal
+dictates of Policy, just the presentation. The same tags are used for
+these bugs for convenience, but the Policy maintainers may make
+informative changes without following the full process. Informative
+bugs fall under their discretion.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=informative">TAG: informative</a>
+</p>
+<p>
+The packaging tag is used for bugs about the packaging and build
+process of the debian-policy Debian package. These bugs do not follow
+the normal process and will not have the other tags except for pending
+and wontfix (used with their normal meanings).
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging">TAG: packaging</a>
+</p></div>
+</div>
+<div id="postamble">
+<p class="author"> Author: Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava
+<a href="mailto:srivasta@debian.org"><srivasta@debian.org></a>
+</p>
+<p class="date"> Date: 2009-09-13 16:13:52 CDT</p>
+<p class="creator">HTML generated by org-mode 6.30trans in emacs 23</p>
+</div>
+</div>
+</body>
+</html>
--- /dev/null
+-*- mode: org; fill-column: 78 -*-
+#+STARTUP: showall
+#+STARTUP: lognotedone lognotestate
+#+OPTIONS: H:4 toc:2
+#+TITLE: Debian Policy changes process
+#+AUTHOR: Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava
+#+EMAIL: srivasta@debian.org
+#+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:nil skip:t d:nil tags:not-in-toc
+#+LINK_HOME: http://wiki.debian.org/Teams/Policy
+#+LINK_UP: http://www.debian.org/
+
+\usepackage{landscape}
+
+\setlength{\oddsidemargin}{0in} % default=0in
+\setlength{\textwidth}{9in} % default=9in
+
+\setlength{\columnsep}{0.5in} % default=10pt
+\setlength{\columnseprule}{1pt} % default=0pt (no line)
+
+\setlength{\textheight}{5.85in} % default=5.15in
+\setlength{\topmargin}{-0.15in} % default=0.20in
+\setlength{\headsep}{0.25in} % default=0.35in
+
+\setlength{\parskip}{1.2ex}
+\setlength{\parindent}{0mm}
+\pagestyle{empty}
+
+\setlength{\headheight}{0pt}
+\setlength{\headsep}{0pt}
+\setlength{\footskip}{5pt}
+\setlength{\textheight}{9.0in}
+\setlength{\textwidth}{6.5in}
+
+To introduce a change in the current DebianPolicy, the change proposal
+has to go through a certain process.
+
+* Change Goals
+
++ The change should be technically correct, and consistent with the
+ rest of the policy document. This means no legislating the value of
+ π. This also means that the proposed solution be known to work;
+ iterative design processes do not belong in policy.
++ The change should not be too disruptive; if very many packages
+ become instantly buggy, then instead there should be a transition
+ plan. Exceptions should be rare (only if the current state is really
+ untenable), and probably blessed by the TC.
++ The change has to be reviewed in depth, in the open, where any one
+ may contribute; a publicly accessible, archived, open mailing list.
++ Proposal should be addressed in a timely fashion.
++ Any domain experts should be consulted, since not every policy
+ mailing list subscriber is an expert on everything, including policy
+ maintainers.
++ The goal is rough consensus on the change, which should not be hard
+ if the matter is technical. Technical issues where there is no
+ agreement should be referred to the TC; non-technical issues should
+ be referred to the whole developer body, and perhaps general
+ resolutions lie down that path.
++ Package maintainers whose packages may be impacted should have
+ access to policy change proposals, even if they do not subscribe to
+ policy mailing lists (policy gazette?).
+
+* Current Process
+
+Each suggested change goes through different states. These states are
+denoted through either usertags of the
+[[mailto:debian-policy@packages.debian.org][debian-policy@packages.debian.org]] user or, for patch, pending, and
+wontfix, regular tags.
+
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done][Current list of bugs]]
+
+The Policy delegates are responsible for managing the tags on bugs and
+will update tags as new bugs are submitted or as activity happens on
+bugs. All Debian Developers should feel free to add the seconded tag
+as described below. Other tags should be changed with the coordination
+of the Policy Team.
+
+** State A: Issue raised
+
+Detect need, like gaps/flaws in current policy, or a new rule should
+be added. Any user or developer may start this step. There is a
+decision point here, not all issues are in scope of policy.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&tag=issue][TAG: issue]]
+
+What needs to happen next: If this is in scope for Policy, discuss the
+issue and possible solutions, moving to the discussion tag, or if the
+matter is sufficiently clear, go directly to a proposal for how to
+address it, moving to the proposal tag. If this is not in scope for
+Policy, close the bug.
+
+** State B: Discussion
+
+Discuss remedy. Alternate proposals. Discussion guided by
+delegates. There should be a clear time limit to this stage, but as
+yet we have not set one.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=discussion][TAG: discussion]]
+
+What needs to happen next: Reach a conclusion and consensus in the
+discussion and make a final proposal for what should be changed (if
+anything), moving to the proposal tag.
+
+** State D: Proposal
+
+A final proposal has emerged from the discussion, and there is a rough
+consensus on how to proceed to resolve the issue.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=proposal][TAG: proposal]]
+
+What needs to happen next: Provided that the rough consensus persists,
+develop a patch against the current Policy document with specific
+wording of the change. Often this is done in conjunction with the
+proposal, in which case one may skip this step and move directly to
+patch tag.
+
+** State E: Wording proposed
+
+A patch against the Policy document reflecting the consensus has been
+created and is waiting for formal seconds. The standard patch tag is
+used for this state, since it's essentially equivalent to the standard
+meaning of that tag.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch][TAG: patch]]
+
+What needs to happen next: The proposal needs to be reviewed and
+seconded. Any Debian developer who agrees with the change and the
+conclusion of rough consensus from the discussion should say so in the
+bug log by seconding the proposal.
+
+** State F: Seconded
+
+The proposal is signed off on by N Debian Developers. To start with,
+we're going with N=3, meaning that if three Debian Developers agree,
+not just with the proposal but with the conclusion that it reflects
+consensus and addresses the original issue -- it is considered
+eligible for inclusion in the next version of Policy. Since Policy is
+partly a technical project governance method, one must be a Debian
+Developer to formally second, although review and discussion is
+welcome from anyone. Once this tag has been applied, the bug is
+waiting for a Policy team member to apply the patch to the package
+repository.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=seconded][TAG: seconded]]
+
+What needs to happen next: A Policy maintainer does the final review
+and confirmation, and then applies the patch for the next Policy
+release.
+
+This tag is not used very much because normally a Policy maintainer
+applies the patch and moves the proposal to the next state once enough
+seconds are reached.
+
+** State G: Accepted
+
+Change accepted, will be in next upload. The standard pending tag is
+used for this state since it matches the regular meaning of
+pending.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=pending][TAG: pending]]
+
+What needs to happen next: The bug is now in the waiting queue for the
+next Policy release, and there's nothing left to do except for upload
+a new version of Policy.
+
+** State H: Reject
+
+Rejected proposals. The standard wontfix is used for this
+state. Normally, bugs in this state will not remain open; instead, a
+Policy team member will close them with an explanation. The submitter
+may then appeal to the tech-ctte if they so desire. Alternately,
+issues appealed to the tech-ctte may remain open with this tag while
+that appeal proceeds.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=rejected][TAG: wontfix]]
+
+We may use one of the following tags here, but to date we have only
+used dubious and ctte. It's not clear whether we need more tags for
+this tage.
+
++ *dubious* :: Not a policy matter
++ *ctte* :: Referred to the Technical Committee (tech-ctte)
++ *devel* :: Referred to the developer body
++ *delegate* :: Rejected by a Policy delegate
++ *obsolete* :: The proposal timed out without a conclusion
+
+What needs to happen next: The bug should be closed once a final
+resolution is reached, or retagged to an appropriate state if that
+final resolution reverses the decision to reject the proposal.
+
+* Other Tags
+
+All Policy bugs are additionally categorized by class of bug.
+
+The normative tag is used for bugs that make normative changes to
+Policy, meaning that the dictates of Policy will change in some
+fashion as part of the resolution of the bug if the proposal is
+accepted. The full process is followed for such bugs.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=normative][TAG: normative]]
+
+The informative tag is used for bugs about wording issues, typos,
+informative footnotes, or other changes that do not affect the formal
+dictates of Policy, just the presentation. The same tags are used for
+these bugs for convenience, but the Policy maintainers may make
+informative changes without following the full process. Informative
+bugs fall under their discretion.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=informative][TAG: informative]]
+
+The packaging tag is used for bugs about the packaging and build
+process of the debian-policy Debian package. These bugs do not follow
+the normal process and will not have the other tags except for pending
+and wontfix (used with their normal meanings).
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging][TAG: packaging]]
--- /dev/null
+ Debian Policy changes process
+ =============================
+
+Author: Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava <srivasta@debian.org>
+Date: 2009-09-13 01:17:13 CDT
+
+
+Change Goals
+~~~~~~~~~~~~~
+
++ The change should be technically correct, and consistent with the
+ rest of the policy document. This means no legislating the value of
+ π. This also means that the proposed solution be known to work;
+ iterative design processes do not belong in policy.
++ The change should not be too disruptive; if very many packages
+ become instantly buggy, then instead there should be a transition
+ plan. Exceptions should be rare (only if the current state is really
+ untenable), and probably blessed by the TC.
++ The change has to be reviewed in depth, in the open, where any one
+ may contribute; a publicly accessible, archived, open mailing list.
++ Proposal should be addressed in a timely fashion.
++ Any domain experts should be consulted, since not every policy
+ mailing list subscriber is an expert on everything, including policy
+ maintainers.
++ The goal is rough consensus on the change, which should not be hard
+ if the matter is technical. Technical issues where there is no
+ agreement should be referred to the TC; non-technical issues should
+ be referred to the whole developer body, and perhaps general
+ resolutions lie down that path.
++ Package maintainers whose packages may be impacted should have
+ access to policy change proposals, even if they do not subscribe to
+ policy mailing lists (policy gazette?).
+
+Current Process
+~~~~~~~~~~~~~~~~
+
+Each suggested change goes through different states. These states are
+denoted through either usertags of the
+[debian-policy@packages.debian.org] user or, for patch, pending, and
+wontfix, regular tags.
+
+[Current list of bugs]
+
+The Policy delegates are responsible for managing the tags on bugs and
+will update tags as new bugs are submitted or as activity happens on
+bugs. All Debian Developers should feel free to add the seconded tag
+as described below. Other tags should be changed with the coordination
+of the Policy Team.
+
+
+[debian-policy@packages.debian.org]: mailto:debian-policy@packages.debian.org
+[Current list of bugs]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done
+
+State A: Issue raised
+======================
+
+Detect need, like gaps/flaws in current policy, or a new rule should
+be added. Any user or developer may start this step. There is a
+decision point here, not all issues are in scope of policy.
+[TAG: issue]
+
+What needs to happen next: If this is in scope for Policy, discuss the
+issue and possible solutions, moving to the discussion tag, or if the
+matter is sufficiently clear, go directly to a proposal for how to
+address it, moving to the proposal tag. If this is not in scope for
+Policy, close the bug.
+
+
+[TAG: issue]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&tag=issue
+
+State B: Discussion
+====================
+
+Discuss remedy. Alternate proposals. Discussion guided by
+delegates. There should be a clear time limit to this stage, but as
+yet we have not set one.
+[TAG: discussion]
+
+What needs to happen next: Reach a conclusion and consensus in the
+discussion and make a final proposal for what should be changed (if
+anything), moving to the proposal tag.
+
+
+[TAG: discussion]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=discussion
+
+State D: Proposal
+==================
+
+A final proposal has emerged from the discussion, and there is a rough
+consensus on how to proceed to resolve the issue.
+[TAG: proposal]
+
+What needs to happen next: Provided that the rough consensus persists,
+develop a patch against the current Policy document with specific
+wording of the change. Often this is done in conjunction with the
+proposal, in which case one may skip this step and move directly to
+patch tag.
+
+
+[TAG: proposal]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=proposal
+
+State E: Wording proposed
+==========================
+
+A patch against the Policy document reflecting the consensus has been
+created and is waiting for formal seconds. The standard patch tag is
+used for this state, since it's essentially equivalent to the standard
+meaning of that tag.
+[TAG: patch]
+
+What needs to happen next: The proposal needs to be reviewed and
+seconded. Any Debian developer who agrees with the change and the
+conclusion of rough consensus from the discussion should say so in the
+bug log by seconding the proposal.
+
+
+[TAG: patch]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch
+
+State F: Seconded
+==================
+
+The proposal is signed off on by N Debian Developers. To start with,
+we're going with N=3, meaning that if three Debian Developers agree,
+not just with the proposal but with the conclusion that it reflects
+consensus and addresses the original issue -- it is considered
+eligible for inclusion in the next version of Policy. Since Policy is
+partly a technical project governance method, one must be a Debian
+Developer to formally second, although review and discussion is
+welcome from anyone. Once this tag has been applied, the bug is
+waiting for a Policy team member to apply the patch to the package
+repository.
+[TAG: seconded]
+
+What needs to happen next: A Policy maintainer does the final review
+and confirmation, and then applies the patch for the next Policy
+release.
+
+This tag is not used very much because normally a Policy maintainer
+applies the patch and moves the proposal to the next state once enough
+seconds are reached.
+
+
+[TAG: seconded]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=seconded
+
+State G: Accepted
+==================
+
+Change accepted, will be in next upload. The standard pending tag is
+used for this state since it matches the regular meaning of
+pending.
+[TAG: pending]
+
+What needs to happen next: The bug is now in the waiting queue for the
+next Policy release, and there's nothing left to do except for upload
+a new version of Policy.
+
+
+[TAG: pending]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=pending
+
+State H: Reject
+================
+
+Rejected proposals. The standard wontfix is used for this
+state. Normally, bugs in this state will not remain open; instead, a
+Policy team member will close them with an explanation. The submitter
+may then appeal to the tech-ctte if they so desire. Alternately,
+issues appealed to the tech-ctte may remain open with this tag while
+that appeal proceeds.
+[TAG: wontfix]
+
+We may use one of the following tags here, but to date we have only
+used dubious and ctte. It's not clear whether we need more tags for
+this tage.
+
+*dubious*: Not a policy matter
+*ctte*: Referred to the Technical Committee (tech-ctte)
+*devel*: Referred to the developer body
+*delegate*: Rejected by a Policy delegate
+*obsolete*: The proposal timed out without a conclusion
+
+What needs to happen next: The bug should be closed once a final
+resolution is reached, or retagged to an appropriate state if that
+final resolution reverses the decision to reject the proposal.
+
+
+[TAG: wontfix]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=rejected
+
+Other Tags
+~~~~~~~~~~~
+
+All Policy bugs are additionally categorized by class of bug.
+
+The normative tag is used for bugs that make normative changes to
+Policy, meaning that the dictates of Policy will change in some
+fashion as part of the resolution of the bug if the proposal is
+accepted. The full process is followed for such bugs.
+[TAG: normative]
+
+The informative tag is used for bugs about wording issues, typos,
+informative footnotes, or other changes that do not affect the formal
+dictates of Policy, just the presentation. The same tags are used for
+these bugs for convenience, but the Policy maintainers may make
+informative changes without following the full process. Informative
+bugs fall under their discretion.
+[TAG: informative]
+
+The packaging tag is used for bugs about the packaging and build
+process of the debian-policy Debian package. These bugs do not follow
+the normal process and will not have the other tags except for pending
+and wontfix (used with their normal meanings).
+[TAG: packaging]
+
+[TAG: normative]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=normative
+[TAG: informative]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=informative
+[TAG: packaging]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging
+
--- /dev/null
+(setq
+ org-export-html-style-include-default nil
+ org-export-html-style
+ "
+<style type=\"text/css\">
+ html { font-family: Times, serif; font-size: 12pt; }
+ .title { text-align: center; }
+ p.verse { margin-left: 3% }
+ pre {
+ border: 1pt solid #AEBDCC;
+ color: #000000;
+ background-color: LightSlateGray;
+ padding: 5pt;
+ font-family: \"Courier New\", courier, monospace;
+ font-size: 90%;
+ overflow:auto;
+ }
+ dt { font-weight: bold; }
+ div.figure { padding: 0.5em; }
+ div.figure p { text-align: center; }
+ .linenr { font-size:smaller }
+ .code-highlighted {background-color:#ffff00;}
+ .org-info-js_info-navigation { border-style:none; }
+ #org-info-js_console-label { font-size:10px; font-weight:bold;
+ white-space:nowrap; }
+ .org-info-js_search-highlight {background-color:#ffff00; color:#000000;
+ font-weight:bold; }
+
+ body {
+ color: DarkSlateGrey;
+ background-color: gainsboro;
+ font-family: Palatino, \"Palatino Linotype\", \"Hoefler Text\", \"Times New Roman\", Times, Georgia, Utopia, serif;
+ }
+ .org-agenda-date { color: #87cefa; }
+ .org-agenda-structure { color: #87cefa; }
+ .org-scheduled { color: #98fb98; }
+ .org-scheduled-previously { color: #ff7f24; }
+ .org-scheduled-today { color: #98fb98; }
+ .org-tag { font-weight: bold; }
+ .org-todo {
+ color: #ffc0cb;
+ font-weight: bold;
+ }
+
+ a {
+ color: inherit;
+ background-color: inherit;
+ font: inherit;
+ text-decoration: inherit;
+ }
+ a:hover { text-decoration: underline; }
+ .todo { font-weight:bold; }
+ .done { font-weight:bold; }
+ .TODO { color:red; }
+ .WAITING { color:orange; }
+ .DONE { color:green; }
+ .timestamp { color: grey }
+ .timestamp-kwd { color: CadetBlue }
+ .tag { background-color:lightblue; font-weight:normal }
+ .target { background-color: lavender; }
+table {
+ border-collapse: collapse; /*separate; */
+ border: outset 3pt;
+ border-spacing: 0pt;
+ /* border-spacing: 5pt; */
+ }
+table td { vertical-align: top; border: 1px solid; }
+table th { vertical-align: top; border: 2px solid; }
+</style>
+<script =\"text/javascript\" language=\"JavaScript\" src=\"/styles/org-info.js\"></script>
+<script type=\"text/javascript\" language=\"JavaScript\">
+/* <![CDATA[ */
+org_html_manager.set(\"LOCAL_TOC\", 0);
+org_html_manager.set(\"VIEW_BUTTONS\", 1);
+org_html_manager.set(\"VIEW\", \"info\");
+org_html_manager.set(\"TOC\", 1);
+org_html_manager.set(\"MOUSE_HINT\", \"underline\"); // could be a background-color like #eeeeee
+org_html_manager.setup ();
+/* ]]> */
+</script>
+")
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"
+lang="en" xml:lang="en">
+<head>
+<div style="text-align:right;font-size:70%;white-space:nowrap;">
+ <a accesskey="h" href="http://www.debian.org/"> UP </a>
+ |
+ <a accesskey="H" href="http://wiki.debian.org/Teams/Policy"> HOME </a>
+</div>
+
+<title>Debian Policy</title>
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
+<meta name="generator" content="Org-mode"/>
+<meta name="generated" content="2009-09-12 17:30:48 CDT"/>
+<meta name="author" content="Manoj Srivastava"/>
+<meta name="description" content=""/>
+<meta name="keywords" content=""/>
+
+<link href="/styles/simple_screen.css" type="text/css" rel="stylesheet" media="screen" />
+<link href="/styles/simple_print.css" type="text/css" rel="stylesheet" media="print" />
+<link href="/styles/common.css" type="text/css" rel="stylesheet" />
+<style type="text/css">
+ html { font-family: Times, serif; font-size: 12pt; }
+ .title { text-align: center; }
+ p.verse { margin-left: 3% }
+ pre {
+ border: 1pt solid #AEBDCC;
+ color: gainsboro;
+ background-color: DarkSlateGrey;
+ padding: 5pt;
+ font-family: "Courier New", courier, monospace;
+ font-size: 90%;
+ overflow:auto;
+ }
+ dt { font-weight: bold; }
+ div.figure { padding: 0.5em; }
+ div.figure p { text-align: center; }
+ .linenr { font-size:smaller }
+ .code-highlighted {background-color:#ffff00;}
+ .org-info-js_info-navigation { border-style:none; }
+ #org-info-js_console-label { font-size:10px; font-weight:bold;
+ white-space:nowrap; }
+ .org-info-js_search-highlight {background-color:#ffff00; color:#000000;
+ font-weight:bold; }
+
+ body {
+ color: LightSlateGray;
+ background-color: #000000;
+ font-family: Palatino, "Palatino Linotype", "Hoefler Text", "Times New Roman", Times, Georgia, Utopia, serif;
+ }
+ .org-agenda-date { color: #87cefa; }
+ .org-agenda-structure { color: #87cefa; }
+ .org-scheduled { color: #98fb98; }
+ .org-scheduled-previously { color: #ff7f24; }
+ .org-scheduled-today { color: #98fb98; }
+ .org-tag { font-weight: bold; }
+ .org-todo {
+ color: #ffc0cb;
+ font-weight: bold;
+ }
+
+ a {
+ color: inherit;
+ background-color: inherit;
+ font: inherit;
+ text-decoration: inherit;
+ }
+ a:hover { text-decoration: underline; }
+ .todo { font-weight:bold; }
+ .done { font-weight:bold; }
+ .TODO { color:red; }
+ .WAITING { color:orange; }
+ .DONE { color:green; }
+ .timestamp { color: grey }
+ .timestamp-kwd { color: CadetBlue }
+ .tag { background-color:lightblue; font-weight:normal }
+ .target { background-color: lavender; }
+table {
+ border-collapse: collapse; /*separate; */
+ border: outset 3pt;
+ border-spacing: 0pt;
+ /* border-spacing: 5pt; */
+ }
+table td { vertical-align: top; border: 1px solid; }
+table th { vertical-align: top; border: 2px solid; }
+</style>
+<script ="text/javascript" language="JavaScript" src="/styles/org-info.js"></script>
+<script type="text/javascript" language="JavaScript">
+/* <![CDATA[ */
+org_html_manager.set("LOCAL_TOC", 0);
+org_html_manager.set("VIEW_BUTTONS", 1);
+org_html_manager.set("VIEW", "info");
+org_html_manager.set("TOC", 1);
+org_html_manager.set("MOUSE_HINT", "underline"); // could be a background-color like #eeeeee
+org_html_manager.setup ();
+/* ]]> */
+</script>
+
+<script type="text/javascript">
+<!--/*--><![CDATA[/*><!--*/
+ function CodeHighlightOn(elem, id)
+ {
+ var target = document.getElementById(id);
+ if(null != target) {
+ elem.cacheClassElem = elem.className;
+ elem.cacheClassTarget = target.className;
+ target.className = "code-highlighted";
+ elem.className = "code-highlighted";
+ }
+ }
+ function CodeHighlightOff(elem, id)
+ {
+ var target = document.getElementById(id);
+ if(elem.cacheClassElem)
+ elem.className = elem.cacheClassElem;
+ if(elem.cacheClassTarget)
+ target.className = elem.cacheClassTarget;
+ }
+/*]]>*///-->
+</script>
+</head>
+<body>
+<div id="content">
+<h1 class="title">Debian Policy</h1>
+
+
+<div id="outline-container-1" class="outline-2">
+<h2 id="sec-1">Infrastructure </h2>
+<div class="outline-text-2" id="text-1">
+
+
+<ul>
+<li>
+Website:: <a href="http://www.debian.org/doc/devel-manuals#policy">http://www.debian.org/doc/devel-manuals#policy</a>
+</li>
+<li>
+Mailing list:: debian-policy@lists.debian.org lists
+</li>
+<li>
+Source Code::
+<ul>
+<li>
+git clone git://git.debian.org/git/dbnpolicy/policy.git
+</li>
+<li>
+Browser: <a href="http://git.debian.org/?p=dbnpolicy/policy.git">http://git.debian.org/?p=dbnpolicy/policy.git</a>
+</li>
+</ul>
+</li>
+<li>
+Unix group:: dbnpolicy
+</li>
+<li>
+Alioth Project:: <a href="http://alioth.debian.org/projects/dbnpolicy">http://alioth.debian.org/projects/dbnpolicy</a> (exists
+to manage the repository but not otherwise used)
+
+</li>
+</ul>
+
+</div>
+
+<div id="outline-container-1.1" class="outline-3">
+<h3 id="sec-1.1">Interacting with the team </h3>
+<div class="outline-text-3" id="text-1.1">
+
+
+<ul>
+<li>
+Email contact:: <a href="mailto:debian-policy@lists.debian.org">mailto:debian-policy@lists.debian.org</a>
+</li>
+<li>
+Request tracker:: <a href="http://bugs.debian.org/src:debian-policy">http://bugs.debian.org/src:debian-policy</a>
+
+</li>
+</ul>
+
+<p>Debian Policy uses a formal procedure and a set of user tags to manage
+the lifecycle of change proposals. For definitions of those tags and
+proposal states and information about what the next step is for each
+phase, see PolicyChangesProcess.
+</p>
+<p>
+Once the wording for a change has been finalized, please send a patch
+against the current Git master branch to the bug report, if you're not
+familiar with Git, the following commands are the basic process:
+</p>
+
+
+
+<pre class="src src-Sh">git clone git://git.debian.org/git/dbnpolicy/policy.git
+git checkout -b <local-branch-name>
+
+# edit files, but don't make changes to upgrading-checklist or debian/changelog
+git add <files>
+git commit
+# repeat as necessary
+
+# update your branch against the current master
+git checkout master
+git pull
+
+# If there are changes in master that make the branch not apply cleanly:
+ : git checkout -b temp master; git merge <local-branch-name>
+# If error, reset temp, merge master into local; else skip these three lines
+ : git reset --hard HEAD;
+ : git checkout <local-branch-name>;
+ : git merge master
+# get rid of the temp branch:
+ : git branch -D temp
+
+# Checkout the local branch, to create the patch to send to the policy
+git checkout <local-branch-name>
+dir=$(mktemp -d)
+git format-patch -o $dir -s master
+# check out the patches created in $dir
+git send-email --from <span style="color: #ffc1c1;">"you <<a href="mailto:your@email">your@email</a>>"</span> \
+ --to debian-policy@lists.debian.org \
+ $dir/
+</pre>
+
+
+
+
+<p>
+<local-branch-name> is some convenient name designating your local
+changes. You may want to use some common prefix like local-. You can
+use git format-patch and git send-email if you want, but usually it's
+overkill.
+</p>
+</div>
+</div>
+
+</div>
+
+<div id="outline-container-2" class="outline-2">
+<h2 id="sec-2">Usual Roles </h2>
+<div class="outline-text-2" id="text-2">
+
+
+<p>
+The Debian Policy team are official project delegates (see the DPL
+delegation). All of the Policy team members do basically the same
+work: shepherd proposals, propose wording, and merge changes when
+consensus has been reached. The current delegates are:
+</p>
+<ul>
+<li>
+Russ Allbery
+</li>
+<li>
+Bill Allombert
+</li>
+<li>
+Andrew McMillan
+</li>
+<li>
+Manoj Srivastava
+</li>
+<li>
+Colin Watson (cjwatson)
+
+</li>
+</ul>
+
+<p>The special tasks of Policy delegates are:
+</p>
+<ul>
+<li>
+Commit access to the Git repository and uploads of the debian-policy
+package itself, which makes them responsible for debian-policy as a
+package in Debian and for making final decisions about when a new
+version is released and what bits go into it.
+</li>
+<li>
+Rejecting proposals. Anyone can argue against a proposal, but only
+Policy delegates can formally reject it.
+</li>
+<li>
+Counting seconds and weighing objections to proposals to determine
+whether the proposal has sufficient support to be included.
+
+</li>
+</ul>
+
+<p>Everything else can be done by anyone, or any DD (depending on the
+outcome of the discussion about seconding). We explicitly want any
+Debian DD to review and second or object to proposals. The more
+participation, the better. Many other people are active on the Policy
+mailing list without being project delegates.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-3" class="outline-2">
+<h2 id="sec-3">Task description </h2>
+<div class="outline-text-2" id="text-3">
+
+
+<p>
+The Debian Policy team is responsible for maintaining and coordinating
+updates to the technical Policy manuals for the project. The primary
+output of the team is the Debian Policy Manual and the assorted
+subpolicies, released as the debian-policy Debian package and also
+published at <a href="http://www.debian.org/doc/">http://www.debian.org/doc/</a>.
+</p>
+<p>
+In addition to the main technical manual, the team currently also maintains:
+</p>
+<ul>
+<li>
+<a href="http://www.debian.org/doc/packaging-manuals/menu-policy/">Debian Menu sub-policy</a>
+</li>
+<li>
+<a href="http://www.debian.org/doc/packaging-manuals/perl-policy/">Debian Perl Policy</a>
+</li>
+<li>
+<a href="http://www.debian.org/doc/packaging-manuals/mime-policy/">Debian MIME support sub-policy</a>
+</li>
+<li>
+<a href="http://www.debian.org/doc/packaging-manuals/debconf_specification.html">Debconf Specification</a>
+</li>
+<li>
+<a href="http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt">Authoritative list of virtual package names </a>
+
+</li>
+</ul>
+
+<p>These documents are maintained using the <a href="http://wiki.debian.org/PolicyChangesProcess">Policy changes process</a>, and
+the current state of all change proposals is tracked using the
+<a href="http://bugs.debian.org/src:debian-policy">debian-policy BTS</a>.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-4" class="outline-2">
+<h2 id="sec-4">Get involved </h2>
+<div class="outline-text-2" id="text-4">
+
+
+<p>
+The best way to help is to review the <a href="http://bugs.debian.org/src:debian-policy">current open bugs</a>, pick a bug
+that no one is currently shepherding (ask on
+<a href="mailto:debian-policy@lists.debian.org">debian-policy@lists.debian.org</a> if you're not sure if a particular bug
+is being shepherded), and help it through the change process. This
+will involve guiding the discussion, seeking additional input
+(particularly from experts in the area being discussed), possibly
+raising the issue on other mailing lists, proposing or getting other
+people to propose specific wording changes, and writing diffs against
+the current Policy document. All of the steps of <a href="http://wiki.debian.org/PolicyChangesProcess">Policy changes process</a>
+can be done by people other than Policy team members except
+the final acceptance steps and almost every change can be worked on
+independently, so there's a lot of opportunity for people to help.
+</p>
+<p>
+There are also some other, larger projects:
+</p>
+<ul>
+<li>
+Policy is currently maintained in DebianDoc-SGML, which is no longer
+very actively maintained and isn't a widely used or understood
+format. The most logical replacement would be DocBook. However,
+DocBook is a huge language with many tags and options, making it
+rather overwhelming. We badly need someone with DocBook experience
+to write a style guide specifying exactly which tags should be used
+and what they should be used for so that we can limit ourselves to
+an easy-to-understand and documented subset of the language.
+</li>
+<li>
+Policy contains several appendices which are really documentation of
+how parts of the dpkg system works rather than technical
+Policy. Those appendices should be removed from the Policy document
+and maintained elsewhere, probably as part of dpkg, and any Policy
+statements in them moved into the main document. This project will
+require reviewing the current contents of the appendices and feeding
+the useful bits that aren't currently documented back to the dpkg
+team as documentation patches.
+</li>
+<li>
+Policy has grown organically over the years and suffers from
+organizational issues because of it. It also doesn't make use of the
+abilities that a current XML language might give us, such as being
+able to extract useful portions of the document (all <b>must</b>
+directives, for example). There has been quite a bit of discussion
+of a new format that would allow for this, probably as part of
+switching to DocBook, but as yet such a reorganization and reworking
+has not been started.
+
+</li>
+</ul>
+
+<p>If you want to work on any of these projects, please mail
+<a href="mailto:debian-policy@lists.debian.org">debian-policy@lists.debian.org </a> for more information. We'll be happy to
+help you get started.
+</p>
+
+</div>
+
+<div id="outline-container-4.1" class="outline-3">
+<h3 id="sec-4.1">Maintenance procedures </h3>
+<div class="outline-text-3" id="text-4.1">
+
+
+</div>
+
+</div>
+
+<div id="outline-container-4.2" class="outline-3">
+<h3 id="sec-4.2">Repository layout </h3>
+<div class="outline-text-3" id="text-4.2">
+
+
+<p>
+The Git repository used for Debian Policy has the following branches:
+</p>
+<ul>
+<li>
+ master:: the current accepted changes that will be in the next release
+</li>
+<li>
+ bug<number>-<user>:: changes addressing bug <number>, shepherded by <user>
+</li>
+<li>
+ rra:: old history of Russ's arch repository, now frozen
+</li>
+<li>
+ srivasta:: old history of Manoj's arch repository
+
+</li>
+</ul>
+</div>
+
+</div>
+
+<div id="outline-container-4.3" class="outline-3">
+<h3 id="sec-4.3">Managing a bug </h3>
+<div class="outline-text-3" id="text-4.3">
+
+
+<p>
+The process used by Policy team members to manage a bug, once there is
+proposed wording, is:
+</p>
+<ul>
+<li>
+Create a bug<number>-<user> branch for the bug, where <number> is
+the bug number in the BTS and <user> is a designator of the Policy
+team member who is shepherding the bug.
+</li>
+<li>
+Commit wording changes in that branch until consensus is
+achieved. Do not modify debian/changelog or upgrading-checklist.html
+during this phase. Use the BTS to track who proposed the wording and
+who seconded it.
+</li>
+<li>
+git pull master to make sure you have the latest version.
+</li>
+<li>
+Once the change has been approved by enough people, git merge the
+branch into master immediately after making the final commit adding
+the changelog entry to minimize conflicts.
+</li>
+<li>
+add the debian/changelog and upgrading-checklist.html changes, and
+commit to master.
+</li>
+<li>
+Push master out so other people may merge in their own bug branches
+without conflicts.
+</li>
+<li>
+Tag the bug as pending and remove other process tags.
+</li>
+<li>
+Delete the now-merged branch.
+
+</li>
+</ul>
+
+<p>The Git commands used for this workflow are:
+</p>
+
+
+<pre class="src src-Sh">git checkout -b bug12345-rra master
+# edit files
+# git add files
+git commit
+git push origin bug12345-rra
+# iterate until good
+# update your local master branch
+git checkout master
+git pull
+# If there are changes in master that make the branch not apply cleanly:
+: git checkout -b temp master; git merge bug12345-rra
+# If error;
+: git reset --hard HEAD;
+: git checkout bug12345-rra; git branch -D temp
+: git merge master
+git checkout master
+git merge bug12345-rra
+# edit debian/changelog and upgrading-checklist.html
+git add debian/changelog upgrading-checklist.html
+git commit
+git push origin master
+git branch -d bug12345-rra
+git push origin :bug12345-rra
+</pre>
+
+
+
+
+<p>
+For the debian/changelog entry, use the following format:
+</p>
+
+
+<pre class="example">* <document>: <brief change description>
+ Wording: <author of wording>
+ Seconded: <seconder>
+ Seconded: <seconder>
+ Closes: <bug numbers>
+</pre>
+
+
+
+
+<p>
+For example:
+</p>
+
+
+<pre class="example">* Policy: better document version ranking and empty Debian revisions
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Raphaël Hertzog <hertzog@debian.org>
+ Seconded: Manoj Srivastava <srivasta@debian.org>
+ Seconded: Guillem Jover <guillem@debian.org>
+ Closes: #186700, #458910
+</pre>
+
+
+
+
+</div>
+
+</div>
+
+<div id="outline-container-4.4" class="outline-3">
+<h3 id="sec-4.4">Updating branches </h3>
+<div class="outline-text-3" id="text-4.4">
+
+
+<p>
+After commits to master have been pushed, either by you or by another
+Policy team member, you will generally want to update your working bug
+branches. The equivalent of the following commands should do that:
+</p>
+
+
+
+<pre class="src src-Sh">for i in `git show-ref --heads | awk '{print $2}'`; do
+ j=$(basename $i)
+ if [ <span style="color: #ffc1c1;">"$j"</span> != <span style="color: #ffc1c1;">"master"</span> ]; then
+ git checkout $j && git merge master
+ fi
+done
+git push --all origin
+</pre>
+
+
+
+
+<p>
+assuming that you haven't packed the refs in your repository.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-4.5" class="outline-3">
+<h3 id="sec-4.5">Making a release </h3>
+<div class="outline-text-3" id="text-4.5">
+
+
+<p>
+For a final Policy release, change UNRELEASED to unstable in
+debian/changelog and update the timestamp to match the final release
+time (dch -r may be helpful for this), update the release date in
+upgrading-checklist.html, update Standards-Version in debian/control,
+and commit that change. Then do the final release build and make sure
+that it builds and installs.
+</p>
+<p>
+Then, tag the repository and push the final changes to Alioth:
+</p>
+
+
+
+<pre class="src src-Sh">git tag -s v3.8.0.0
+git push origin
+git push --tags origin
+</pre>
+
+
+
+
+<p>
+replacing the version number with the version of the release, of course.
+</p>
+<p>
+Finally, announce the new Policy release on debian-devel-announce,
+including in the announcement the upgrading-checklist section for the
+new release.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-4.6" class="outline-3">
+<h3 id="sec-4.6">Setting release goals </h3>
+<div class="outline-text-3" id="text-4.6">
+
+
+<p>
+Policy has a large bug backlog, and each bug against Policy tends to
+take considerable time and discussion to resolve. I've found it
+useful, when trying to find a place to start, to pick a manageable set
+of bugs and set as a target resolving them completely before the next
+Policy release. Resolving a bug means one of the following:
+</p>
+<ul>
+<li>
+Proposing new language to address the bug that's seconded and
+approved by the readers of the Policy list following the
+PolicyChangesProcess (or that's accepted by one of the Policy
+delegates if the change isn't normative; i.e., doesn't change the
+technical meaning of the document).
+</li>
+<li>
+Determining that the bug is not relevant to Policy and closing it.
+</li>
+<li>
+Determining that either there is no consensus that the bug indicates
+a problem, that the solutions that we can currently come up with are
+good solutions, or that Debian is ready for the change. These bugs
+are tagged wontfix and then closed after a while. A lot of Policy
+bugs fall into this category; just because it would be useful to
+have a policy in some area doesn't mean that we're ready to make
+one, and keeping the bugs open against Policy makes it difficult to
+tell what requires work. If the problem is worth writing a policy
+for, it will come up again later when hopefully the project
+consensus is more mature.
+
+</li>
+</ul>
+
+<p>Anyone can pick bugs and work resolve them. The final determination to
+accept a wording change or reject a bug will be made by a Policy
+delegate, but if a patch is already written and seconded, or if a
+summary of why a bug is not ready to be acted on is already written,
+the work is much easier for the Policy delegate.
+</p>
+<p>
+One of the best ways to help out is to pick one or two bugs (checking
+on the Policy list first), say that you'll make resolving them a goal
+for the next release, and guide the discussion until the bugs can
+reach one of the resolution states above.
+</p></div>
+</div>
+</div>
+<div id="postamble">
+<p class="author"> Author: Manoj Srivastava
+<a href="mailto:srivasta@debian.org"><srivasta@debian.org></a>
+</p>
+<p class="date"> Date: 2009-09-12 17:30:48 CDT</p>
+<p class="creator">HTML generated by org-mode 6.30trans in emacs 23</p>
+</div>
+</div>
+</body>
+</html>
--- /dev/null
+-*- mode: org; fill-column: 78 -*-
+#+STARTUP: showall
+#+STARTUP: lognotedone lognotestate
+#+OPTIONS: H:4 toc:2
+#+TITLE: Debian Policy
+#+AUTHOR: Manoj Srivastava And Russ Allbery
+#+EMAIL: srivasta@debian.org
+#+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:nil skip:t d:nil tags:not-in-toc
+#+LINK_HOME: http://wiki.debian.org/Teams/Policy
+#+LINK_UP: http://www.debian.org/
+
+\usepackage{landscape}
+
+\setlength{\oddsidemargin}{0in} % default=0in
+\setlength{\textwidth}{9in} % default=9in
+
+\setlength{\columnsep}{0.5in} % default=10pt
+\setlength{\columnseprule}{1pt} % default=0pt (no line)
+
+\setlength{\textheight}{5.85in} % default=5.15in
+\setlength{\topmargin}{-0.15in} % default=0.20in
+\setlength{\headsep}{0.25in} % default=0.35in
+
+\setlength{\parskip}{1.2ex}
+\setlength{\parindent}{0mm}
+\pagestyle{empty}
+
+\setlength{\headheight}{0pt}
+\setlength{\headsep}{0pt}
+\setlength{\footskip}{5pt}
+\setlength{\textheight}{9.0in}
+\setlength{\textwidth}{6.5in}
+
+
+* Infrastructure
+
++ Website:: http://www.debian.org/doc/devel-manuals#policy
++ Mailing list:: debian-policy@lists.debian.org lists
++ Source Code::
+ * git clone git://git.debian.org/git/dbnpolicy/policy.git
+ * Browser: http://git.debian.org/?p=dbnpolicy/policy.git
++ Unix group:: dbnpolicy
++ Alioth Project:: http://alioth.debian.org/projects/dbnpolicy (exists
+ to manage the repository but not otherwise used)
+
+** Interacting with the team
+
++ Email contact:: mailto:debian-policy@lists.debian.org
++ Request tracker:: http://bugs.debian.org/src:debian-policy
+
+Debian Policy uses a formal procedure and a set of user tags to manage
+the lifecycle of change proposals. For definitions of those tags and
+proposal states and information about what the next step is for each
+phase, see PolicyChangesProcess.
+
+Once the wording for a change has been finalized, please send a patch
+against the current Git master branch to the bug report, if you're not
+familiar with Git, the following commands are the basic process:
+
+#+BEGIN_SRC Sh
+git clone git://git.debian.org/git/dbnpolicy/policy.git
+git checkout -b <local-branch-name>
+
+# edit files, but don't make changes to upgrading-checklist or debian/changelog
+git add <files>
+git commit
+# repeat as necessary
+
+# update your branch against the current master
+git checkout master
+git pull
+
+# If there are changes in master that make the branch not apply cleanly:
+ : git checkout -b temp master; git merge <local-branch-name>
+# If error, reset temp, merge master into local; else skip these three lines
+ : git reset --hard HEAD;
+ : git checkout <local-branch-name>;
+ : git merge master
+# get rid of the temp branch:
+ : git branch -D temp
+
+# Checkout the local branch, to create the patch to send to the policy
+git checkout <local-branch-name>
+dir=$(mktemp -d)
+git format-patch -o $dir -s master
+# check out the patches created in $dir
+git send-email --from "you <your@email>" \
+ --to debian-policy@lists.debian.org \
+ $dir/
+#+END_SRC
+
+<local-branch-name> is some convenient name designating your local
+changes. You may want to use some common prefix like local-. You can
+use git format-patch and git send-email if you want, but usually it's
+overkill.
+
+* Usual Roles
+
+The Debian Policy team are official project delegates (see the DPL
+delegation). All of the Policy team members do basically the same
+work: shepherd proposals, propose wording, and merge changes when
+consensus has been reached. The current delegates are:
+
++ Russ Allbery
++ Bill Allombert
++ Andrew McMillan
++ Manoj Srivastava
++ Colin Watson (cjwatson)
+
+The special tasks of Policy delegates are:
+
++ Commit access to the Git repository and uploads of the debian-policy
+ package itself, which makes them responsible for debian-policy as a
+ package in Debian and for making final decisions about when a new
+ version is released and what bits go into it.
++ Rejecting proposals. Anyone can argue against a proposal, but only
+ Policy delegates can formally reject it.
++ Counting seconds and weighing objections to proposals to determine
+ whether the proposal has sufficient support to be included.
+
+Everything else can be done by anyone, or any DD (depending on the
+outcome of the discussion about seconding). We explicitly want any
+Debian DD to review and second or object to proposals. The more
+participation, the better. Many other people are active on the Policy
+mailing list without being project delegates.
+
+* Task description
+
+The Debian Policy team is responsible for maintaining and coordinating
+updates to the technical Policy manuals for the project. The primary
+output of the team is the Debian Policy Manual and the assorted
+subpolicies, released as the debian-policy Debian package and also
+published at [[http://www.debian.org/doc/]].
+
+In addition to the main technical manual, the team currently also maintains:
+
++ [[http://www.debian.org/doc/packaging-manuals/menu-policy/][Debian Menu sub-policy]]
++ [[http://www.debian.org/doc/packaging-manuals/perl-policy/][Debian Perl Policy]]
++ [[http://www.debian.org/doc/packaging-manuals/mime-policy/][Debian MIME support sub-policy]]
++ [[http://www.debian.org/doc/packaging-manuals/debconf_specification.html][Debconf Specification]]
++ [[http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt][Authoritative list of virtual package names ]]
+
+These documents are maintained using the [[http://wiki.debian.org/PolicyChangesProcess][Policy changes process]], and
+the current state of all change proposals is tracked using the
+[[http://bugs.debian.org/src:debian-policy][debian-policy BTS]].
+
+* Get involved
+
+The best way to help is to review the [[http://bugs.debian.org/src:debian-policy][current open bugs]], pick a bug
+that no one is currently shepherding (ask on
+[[mailto:debian-policy@lists.debian.org][debian-policy@lists.debian.org]] if you're not sure if a particular bug
+is being shepherded), and help it through the change process. This
+will involve guiding the discussion, seeking additional input
+(particularly from experts in the area being discussed), possibly
+raising the issue on other mailing lists, proposing or getting other
+people to propose specific wording changes, and writing diffs against
+the current Policy document. All of the steps of [[http://wiki.debian.org/PolicyChangesProcess][Policy changes process]]
+can be done by people other than Policy team members except
+the final acceptance steps and almost every change can be worked on
+independently, so there's a lot of opportunity for people to help.
+
+There are also some other, larger projects:
+
++ Policy is currently maintained in DebianDoc-SGML, which is no longer
+ very actively maintained and isn't a widely used or understood
+ format. The most logical replacement would be DocBook. However,
+ DocBook is a huge language with many tags and options, making it
+ rather overwhelming. We badly need someone with DocBook experience
+ to write a style guide specifying exactly which tags should be used
+ and what they should be used for so that we can limit ourselves to
+ an easy-to-understand and documented subset of the language.
++ Policy contains several appendices which are really documentation of
+ how parts of the dpkg system works rather than technical
+ Policy. Those appendices should be removed from the Policy document
+ and maintained elsewhere, probably as part of dpkg, and any Policy
+ statements in them moved into the main document. This project will
+ require reviewing the current contents of the appendices and feeding
+ the useful bits that aren't currently documented back to the dpkg
+ team as documentation patches.
++ Policy has grown organically over the years and suffers from
+ organizational issues because of it. It also doesn't make use of the
+ abilities that a current XML language might give us, such as being
+ able to extract useful portions of the document (all *must*
+ directives, for example). There has been quite a bit of discussion
+ of a new format that would allow for this, probably as part of
+ switching to DocBook, but as yet such a reorganization and reworking
+ has not been started.
+
+If you want to work on any of these projects, please mail
+[[mailto:debian-policy@lists.debian.org][debian-policy@lists.debian.org ]] for more information. We'll be happy to
+help you get started.
+
+** Maintenance procedures
+
+** Repository layout
+
+The Git repository used for Debian Policy has the following branches:
+
++ master:: the current accepted changes that will be in the next release
++ bug<number>-<user>:: changes addressing bug <number>, shepherded by <user>
++ rra:: old history of Russ's arch repository, now frozen
++ srivasta:: old history of Manoj's arch repository
+
+** Managing a bug
+
+The process used by Policy team members to manage a bug, once there is
+proposed wording, is:
+
++ Create a bug<number>-<user> branch for the bug, where <number> is
+ the bug number in the BTS and <user> is a designator of the Policy
+ team member who is shepherding the bug.
++ Commit wording changes in that branch until consensus is
+ achieved. Do not modify debian/changelog or upgrading-checklist.html
+ during this phase. Use the BTS to track who proposed the wording and
+ who seconded it.
++ git pull master to make sure you have the latest version.
++ Once the change has been approved by enough people, git merge the
+ branch into master immediately after making the final commit adding
+ the changelog entry to minimize conflicts.
++ add the debian/changelog and upgrading-checklist.html changes, and
+ commit to master.
++ Push master out so other people may merge in their own bug branches
+ without conflicts.
++ Tag the bug as pending and remove other process tags.
++ Delete the now-merged branch.
+
+The Git commands used for this workflow are:
+#+BEGIN_SRC Sh
+git checkout -b bug12345-rra master
+# edit files
+# git add files
+git commit
+git push origin bug12345-rra
+# iterate until good
+# update your local master branch
+git checkout master
+git pull
+# If there are changes in master that make the branch not apply cleanly:
+: git checkout -b temp master; git merge bug12345-rra
+# If error;
+: git reset --hard HEAD;
+: git checkout bug12345-rra; git branch -D temp
+: git merge master
+git checkout master
+git merge bug12345-rra
+# edit debian/changelog and upgrading-checklist.html
+git add debian/changelog upgrading-checklist.html
+git commit
+git push origin master
+git branch -d bug12345-rra
+git push origin :bug12345-rra
+#+END_SRC
+
+For the debian/changelog entry, use the following format:
+#+BEGIN_EXAMPLE
+ * <document>: <brief change description>
+ Wording: <author of wording>
+ Seconded: <seconder>
+ Seconded: <seconder>
+ Closes: <bug numbers>
+#+END_EXAMPLE
+
+For example:
+#+BEGIN_EXAMPLE
+ * Policy: better document version ranking and empty Debian revisions
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Raphaël Hertzog <hertzog@debian.org>
+ Seconded: Manoj Srivastava <srivasta@debian.org>
+ Seconded: Guillem Jover <guillem@debian.org>
+ Closes: #186700, #458910
+#+END_EXAMPLE
+
+** Updating branches
+
+After commits to master have been pushed, either by you or by another
+Policy team member, you will generally want to update your working bug
+branches. The equivalent of the following commands should do that:
+
+#+BEGIN_SRC Sh
+for i in `git show-ref --heads | awk '{print $2}'`; do
+ j=$(basename $i)
+ if [ "$j" != "master" ]; then
+ git checkout $j && git merge master
+ fi
+done
+git push --all origin
+#+END_SRC
+
+assuming that you haven't packed the refs in your repository.
+
+** Making a release
+
+For a final Policy release, change UNRELEASED to unstable in
+debian/changelog and update the timestamp to match the final release
+time (dch -r may be helpful for this), update the release date in
+upgrading-checklist.html, update Standards-Version in debian/control,
+and commit that change. Then do the final release build and make sure
+that it builds and installs.
+
+Then, tag the repository and push the final changes to Alioth:
+
+#+BEGIN_SRC Sh
+git tag -s v3.8.0.0
+git push origin
+git push --tags origin
+#+END_SRC
+
+replacing the version number with the version of the release, of course.
+
+Finally, announce the new Policy release on debian-devel-announce,
+including in the announcement the upgrading-checklist section for the
+new release.
+
+** Setting release goals
+
+Policy has a large bug backlog, and each bug against Policy tends to
+take considerable time and discussion to resolve. I've found it
+useful, when trying to find a place to start, to pick a manageable set
+of bugs and set as a target resolving them completely before the next
+Policy release. Resolving a bug means one of the following:
+
++ Proposing new language to address the bug that's seconded and
+ approved by the readers of the Policy list following the
+ PolicyChangesProcess (or that's accepted by one of the Policy
+ delegates if the change isn't normative; i.e., doesn't change the
+ technical meaning of the document).
++ Determining that the bug is not relevant to Policy and closing it.
++ Determining that either there is no consensus that the bug indicates
+ a problem, that the solutions that we can currently come up with are
+ good solutions, or that Debian is ready for the change. These bugs
+ are tagged wontfix and then closed after a while. A lot of Policy
+ bugs fall into this category; just because it would be useful to
+ have a policy in some area doesn't mean that we're ready to make
+ one, and keeping the bugs open against Policy makes it difficult to
+ tell what requires work. If the problem is worth writing a policy
+ for, it will come up again later when hopefully the project
+ consensus is more mature.
+
+Anyone can pick bugs and work resolve them. The final determination to
+accept a wording change or reject a bug will be made by a Policy
+delegate, but if a patch is already written and seconded, or if a
+summary of why a bug is not ready to be acted on is already written,
+the work is much easier for the Policy delegate.
+
+One of the best ways to help out is to pick one or two bugs (checking
+on the Policy list first), say that you'll make resolving them a goal
+for the next release, and guide the discussion until the bugs can
+reach one of the resolution states above.
--- /dev/null
+ Debian Policy
+ =============
+
+Author: Manoj Srivastava <srivasta@debian.org>
+Date: 2009-09-13 00:31:16 CDT
+
+
+Infrastructure
+~~~~~~~~~~~~~~~
+
++ Website:: [http://www.debian.org/doc/devel-manuals#policy]
++ Mailing list:: debian-policy@lists.debian.org lists
++ Source Code::
+ * git clone git://git.debian.org/git/dbnpolicy/policy.git
+ * Browser: [http://git.debian.org/?p=dbnpolicy/policy.git]
++ Unix group:: dbnpolicy
++ Alioth Project:: [http://alioth.debian.org/projects/dbnpolicy] (exists
+ to manage the repository but not otherwise used)
+
+Interacting with the team
+==========================
+
++ Email contact:: [mailto:debian-policy@lists.debian.org]
++ Request tracker:: [http://bugs.debian.org/src:debian-policy]
+
+Debian Policy uses a formal procedure and a set of user tags to manage
+the lifecycle of change proposals. For definitions of those tags and
+proposal states and information about what the next step is for each
+phase, see PolicyChangesProcess.
+
+Once the wording for a change has been finalized, please send a patch
+against the current Git master branch to the bug report, if you're not
+familiar with Git, the following commands are the basic process:
+
+ git clone git://git.debian.org/git/dbnpolicy/policy.git
+ git checkout -b <local-branch-name>
+
+ # edit files, but don't make changes to upgrading-checklist or debian/changelog
+ git add <files>
+ git commit
+ # repeat as necessary
+
+ # update your branch against the current master
+ git checkout master
+ git pull
+
+ # If there are changes in master that make the branch not apply cleanly:
+ git checkout -b temp master; git merge <local-branch-name>
+ # If error, reset temp, merge master into local; else skip these three lines
+ git reset --hard HEAD;
+ git checkout <local-branch-name>;
+ git merge master
+ # get rid of the temp branch:
+ git branch -D temp
+
+ # Checkout the local branch, to create the patch to send to the policy
+ git checkout <local-branch-name>
+ dir=$(mktemp -d)
+ git format-patch -o $dir -s master
+ # check out the patches created in $dir
+ git send-email --from "you <your@email>" \
+ --to debian-policy@lists.debian.org \
+ $dir/
+
+
+<local-branch-name> is some convenient name designating your local
+changes. You may want to use some common prefix like local-. You can
+use git format-patch and git send-email if you want, but usually it's
+overkill.
+
+Usual Roles
+~~~~~~~~~~~~
+
+The Debian Policy team are official project delegates (see the DPL
+delegation). All of the Policy team members do basically the same
+work: shepherd proposals, propose wording, and merge changes when
+consensus has been reached. The current delegates are:
+
++ Russ Allbery
++ Bill Allombert
++ Andrew McMillan
++ Manoj Srivastava
++ Colin Watson (cjwatson)
+
+The special tasks of Policy delegates are:
+
++ Commit access to the Git repository and uploads of the debian-policy
+ package itself, which makes them responsible for debian-policy as a
+ package in Debian and for making final decisions about when a new
+ version is released and what bits go into it.
++ Rejecting proposals. Anyone can argue against a proposal, but only
+ Policy delegates can formally reject it.
++ Counting seconds and weighing objections to proposals to determine
+ whether the proposal has sufficient support to be included.
+
+Everything else can be done by anyone, or any DD (depending on the
+outcome of the discussion about seconding). We explicitly want any
+Debian DD to review and second or object to proposals. The more
+participation, the better. Many other people are active on the Policy
+mailing list without being project delegates.
+
+Task description
+~~~~~~~~~~~~~~~~~
+
+The Debian Policy team is responsible for maintaining and coordinating
+updates to the technical Policy manuals for the project. The primary
+output of the team is the Debian Policy Manual and the assorted
+subpolicies, released as the debian-policy Debian package and also
+published at [http://www.debian.org/doc/].
+
+In addition to the main technical manual, the team currently also maintains:
+
++ [Debian Menu sub-policy]
++ [Debian Perl Policy]
++ [Debian MIME support sub-policy]
++ [Debconf Specification]
++ [Authoritative list of virtual package names ]
+
+These documents are maintained using the [Policy changes process], and
+the current state of all change proposals is tracked using the
+[debian-policy BTS].
+
+
+[Debian Menu sub-policy]: http://www.debian.org/doc/packaging-manuals/menu-policy/
+[Debian Perl Policy]: http://www.debian.org/doc/packaging-manuals/perl-policy/
+[Debian MIME support sub-policy]: http://www.debian.org/doc/packaging-manuals/mime-policy/
+[Debconf Specification]: http://www.debian.org/doc/packaging-manuals/debconf_specification.html
+[Authoritative list of virtual package names ]: http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
+[Policy changes process]: http://wiki.debian.org/PolicyChangesProcess
+[debian-policy BTS]: http://bugs.debian.org/src:debian-policy
+
+Get involved
+~~~~~~~~~~~~~
+
+The best way to help is to review the [current open bugs], pick a bug
+that no one is currently shepherding (ask on
+[debian-policy@lists.debian.org] if you're not sure if a particular bug
+is being shepherded), and help it through the change process. This
+will involve guiding the discussion, seeking additional input
+(particularly from experts in the area being discussed), possibly
+raising the issue on other mailing lists, proposing or getting other
+people to propose specific wording changes, and writing diffs against
+the current Policy document. All of the steps of [Policy changes process]
+can be done by people other than Policy team members except
+the final acceptance steps and almost every change can be worked on
+independently, so there's a lot of opportunity for people to help.
+
+There are also some other, larger projects:
+
++ Policy is currently maintained in DebianDoc-SGML, which is no longer
+ very actively maintained and isn't a widely used or understood
+ format. The most logical replacement would be DocBook. However,
+ DocBook is a huge language with many tags and options, making it
+ rather overwhelming. We badly need someone with DocBook experience
+ to write a style guide specifying exactly which tags should be used
+ and what they should be used for so that we can limit ourselves to
+ an easy-to-understand and documented subset of the language.
++ Policy contains several appendices which are really documentation of
+ how parts of the dpkg system works rather than technical
+ Policy. Those appendices should be removed from the Policy document
+ and maintained elsewhere, probably as part of dpkg, and any Policy
+ statements in them moved into the main document. This project will
+ require reviewing the current contents of the appendices and feeding
+ the useful bits that aren't currently documented back to the dpkg
+ team as documentation patches.
++ Policy has grown organically over the years and suffers from
+ organizational issues because of it. It also doesn't make use of the
+ abilities that a current XML language might give us, such as being
+ able to extract useful portions of the document (all *must*
+ directives, for example). There has been quite a bit of discussion
+ of a new format that would allow for this, probably as part of
+ switching to DocBook, but as yet such a reorganization and reworking
+ has not been started.
+
+If you want to work on any of these projects, please mail
+[debian-policy@lists.debian.org ] for more information. We'll be happy to
+help you get started.
+
+
+[current open bugs]: http://bugs.debian.org/src:debian-policy
+[debian-policy@lists.debian.org]: mailto:debian-policy@lists.debian.org
+[Policy changes process]: http://wiki.debian.org/PolicyChangesProcess
+[debian-policy@lists.debian.org ]: mailto:debian-policy@lists.debian.org
+
+Maintenance procedures
+=======================
+
+Repository layout
+==================
+
+The Git repository used for Debian Policy has the following branches:
+
++ master:: the current accepted changes that will be in the next release
++ bug<number>-<user>:: changes addressing bug <number>, shepherded by <user>
++ rra:: old history of Russ's arch repository, now frozen
++ srivasta:: old history of Manoj's arch repository
+
+Managing a bug
+===============
+
+The process used by Policy team members to manage a bug, once there is
+proposed wording, is:
+
++ Create a bug<number>-<user> branch for the bug, where <number> is
+ the bug number in the BTS and <user> is a designator of the Policy
+ team member who is shepherding the bug.
++ Commit wording changes in that branch until consensus is
+ achieved. Do not modify debian/changelog or upgrading-checklist.html
+ during this phase. Use the BTS to track who proposed the wording and
+ who seconded it.
++ git pull master to make sure you have the latest version.
++ Once the change has been approved by enough people, git merge the
+ branch into master immediately after making the final commit adding
+ the changelog entry to minimize conflicts.
++ add the debian/changelog and upgrading-checklist.html changes, and
+ commit to master.
++ Push master out so other people may merge in their own bug branches
+ without conflicts.
++ Tag the bug as pending and remove other process tags.
++ Delete the now-merged branch.
+
+The Git commands used for this workflow are:
+ git checkout -b bug12345-rra master
+ # edit files
+ # git add files
+ git commit
+ git push origin bug12345-rra
+ # iterate until good
+ # update your local master branch
+ git checkout master
+ git pull
+ # If there are changes in master that make the branch not apply cleanly:
+ git checkout -b temp master; git merge bug12345-rra
+ # If error;
+ git reset --hard HEAD;
+ git checkout bug12345-rra; git branch -D temp
+ git merge master
+ git checkout master
+ git merge bug12345-rra
+ # edit debian/changelog and upgrading-checklist.html
+ git add debian/changelog upgrading-checklist.html
+ git commit
+ git push origin master
+ git branch -d bug12345-rra
+ git push origin :bug12345-rra
+
+
+For the debian/changelog entry, use the following format:
+ * <document>: <brief change description>
+ Wording: <author of wording>
+ Seconded: <seconder>
+ Seconded: <seconder>
+ Closes: <bug numbers>
+
+
+For example:
+ * Policy: better document version ranking and empty Debian revisions
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Raphaël Hertzog <hertzog@debian.org>
+ Seconded: Manoj Srivastava <srivasta@debian.org>
+ Seconded: Guillem Jover <guillem@debian.org>
+ Closes: #186700, #458910
+
+
+Updating branches
+==================
+
+After commits to master have been pushed, either by you or by another
+Policy team member, you will generally want to update your working bug
+branches. The equivalent of the following commands should do that:
+
+ for i in `git show-ref --heads | awk '{print $2}'`; do
+ j=$(basename $i)
+ if [ "$j" != "master" ]; then
+ git checkout $j && git merge master
+ fi
+ done
+ git push --all origin
+
+
+assuming that you haven't packed the refs in your repository.
+
+Making a release
+=================
+
+For a final Policy release, change UNRELEASED to unstable in
+debian/changelog and update the timestamp to match the final release
+time (dch -r may be helpful for this), update the release date in
+upgrading-checklist.html, update Standards-Version in debian/control,
+and commit that change. Then do the final release build and make sure
+that it builds and installs.
+
+Then, tag the repository and push the final changes to Alioth:
+
+ git tag -s v3.8.0.0
+ git push origin
+ git push --tags origin
+
+
+replacing the version number with the version of the release, of course.
+
+Finally, announce the new Policy release on debian-devel-announce,
+including in the announcement the upgrading-checklist section for the
+new release.
+
+Setting release goals
+======================
+
+Policy has a large bug backlog, and each bug against Policy tends to
+take considerable time and discussion to resolve. I've found it
+useful, when trying to find a place to start, to pick a manageable set
+of bugs and set as a target resolving them completely before the next
+Policy release. Resolving a bug means one of the following:
+
++ Proposing new language to address the bug that's seconded and
+ approved by the readers of the Policy list following the
+ PolicyChangesProcess (or that's accepted by one of the Policy
+ delegates if the change isn't normative; i.e., doesn't change the
+ technical meaning of the document).
++ Determining that the bug is not relevant to Policy and closing it.
++ Determining that either there is no consensus that the bug indicates
+ a problem, that the solutions that we can currently come up with are
+ good solutions, or that Debian is ready for the change. These bugs
+ are tagged wontfix and then closed after a while. A lot of Policy
+ bugs fall into this category; just because it would be useful to
+ have a policy in some area doesn't mean that we're ready to make
+ one, and keeping the bugs open against Policy makes it difficult to
+ tell what requires work. If the problem is worth writing a policy
+ for, it will come up again later when hopefully the project
+ consensus is more mature.
+
+Anyone can pick bugs and work resolve them. The final determination to
+accept a wording change or reject a bug will be made by a Policy
+delegate, but if a patch is already written and seconded, or if a
+summary of why a bug is not ready to be acted on is already written,
+the work is much easier for the Policy delegate.
+
+One of the best ways to help out is to pick one or two bugs (checking
+on the Policy list first), say that you'll make resolving them a goal
+for the next release, and guide the discussion until the bugs can
+reach one of the resolution states above.
date := $(shell date +"%Y-%m-%d")
version := $(shell awk -F '[()]' '/^$(package)/{ print $$2; exit }' debian/changelog)
+# either /usr/bin/emacs-snampshot or /usr/bin/emacs23
+EMACS:=$(shell if [ -x /usr/bin/emacs-snapshot ]; then \
+ echo /usr/bin/emacs-snapshot; \
+ elif [ -x /usr/bin/emacs23 ]; then \
+ echo /usr/bin/emacs23; \
+ fi)
+HAVE_ORG_EMACS:=$(strip $(EMACS))
+
+
# Location of the source dir
SRCTOP := $(CURDIR)
TMPTOP := $(SRCTOP)/debian/tmp
upgrading-checklist.txt libc6-migration.txt version.ent \
debconf_spec/debconf_specification.html \
debconf_spec/debconf_specification.txt.gz \
- policy.ps.gz policy.pdf.gz
+ policy.ps.gz policy.pdf.gz README.txt README.html \
+ Process.txt Process.html
# policy.{pdf,ps,tpt,txt} are generated files
FILES_TO_CLEAN = debian/files debian/buildinfo debian/substvars \
policy.pdf policy.ps policy.txt policy. \
body.tmp head.tmp policy.tpt
+FILES_FROM_ORG := README.txt README.html
+
STAMPS_TO_CLEAN := stamp-policy stamp-build
DIRS_TO_CLEAN := debian/tmp fhs $(SGML_FILES:=.html)
$(SGML_FILES:=-1.html) \
$(SGML_FILES:=.txt.gz) \
policy.ps.gz policy.pdf.gz
+ifneq (,$(strip $(HAVE_ORG_EMACS)))
+ $(MAKE) $(FILES_FROM_ORG)
+endif
links -dump upgrading-checklist.html | perl -pe 's/[\r\0]//g' > \
upgrading-checklist.txt
$(MAKE) -C debconf_spec all
projects / debian / debian-policy.git / commitdiff