Bug#545548: [PATCH 1/3] [bug545548-srivasta]: Add Documentation
This patch add a README file, rendered as txt and html, and also
documents the policy change process, again rendered as text and
HTML. While the text and HTML files are automatically generated, they are
shipped in the package itself so as to avoud depending on a recent
version of Emacs during build.
The contents of the new documents are based on (but no identical to) the
contents of related pages on the Debian wiki. The long term plan is to
make these documents the canonical ones, and have the Wiki point to these
pages.
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
---
.gitignore | 1 -
Makefile | 9 +
Process.html | 423 +++++++++++++++++++++++++++++++++++
Process.org | 205 +++++++++++++++++
Process.txt | 216 ++++++++++++++++++
README-css.el | 81 +++++++
README.html | 683 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
README.org | 348 +++++++++++++++++++++++++++++
README.txt | 341 ++++++++++++++++++++++++++++
debian/rules | 17 ++-
10 files changed, 2322 insertions(+), 2 deletions(-)
create mode 100644 Process.html
create mode 100644 Process.org
create mode 100644 Process.txt
create mode 100644 README-css.el
create mode 100644 README.html
create mode 100644 README.org
create mode 100644 README.txt
diff --git a/.gitignore b/.gitignore
index ab942fa..8f14f13 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,5 +14,4 @@
*.ps
*.ps.gz
*.tpt
-*.txt
*.txt.gz
diff --git a/Makefile b/Makefile
index 1d0852e..d9031ff 100644
--- a/Makefile
+++ b/Makefile
@@ -4,6 +4,15 @@ policy.sgml: version.ent
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 $<
diff --git a/Process.html b/Process.html
new file mode 100644
index 0000000..9440ae7
--- /dev/null
+++ b/Process.html
@@ -0,0 +1,423 @@
+<?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>
diff --git a/Process.org b/Process.org
new file mode 100644
index 0000000..7cb0544
--- /dev/null
+++ b/Process.org
@@ -0,0 +1,205 @@
+-*- 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]]
diff --git a/Process.txt b/Process.txt
new file mode 100644
index 0000000..f130c1d
--- /dev/null
+++ b/Process.txt
@@ -0,0 +1,216 @@
+ 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
+
diff --git a/README-css.el b/README-css.el
new file mode 100644
index 0000000..9b7cf85
--- /dev/null
+++ b/README-css.el
@@ -0,0 +1,81 @@
+(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>
+")
diff --git a/README.html b/README.html
new file mode 100644
index 0000000..765c626
--- /dev/null
+++ b/README.html
@@ -0,0 +1,683 @@
+<?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>
diff --git a/README.org b/README.org
new file mode 100644
index 0000000..3228229
--- /dev/null
+++ b/README.org
@@ -0,0 +1,348 @@
+-*- 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.
diff --git a/README.txt b/README.txt
new file mode 100644
index 0000000..ff48eaa
--- /dev/null
+++ b/README.txt
@@ -0,0 +1,341 @@
+ 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.
diff --git a/debian/rules b/debian/rules
index 07e635e..43f2157 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,6 +21,15 @@ package := $(shell grep Source debian/control | sed 's/^Source: //')
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
@@ -48,7 +57,8 @@ POLICY_FILES = $(SGML_FILES:=.sgml) $(SGML_FILES:=.txt.gz) \
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 \
@@ -61,6 +71,8 @@ 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)
@@ -77,6 +89,9 @@ stamp-build: version.ent $(sanitycheck)
$(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
--
1.6.3.3
Reply to: