=== modified file '.gitignore'
--- .gitignore	2010-06-02 17:04:22 +0000
+++ .gitignore	2010-08-25 02:28:21 +0000
@@ -9,6 +9,8 @@
 /stamp-build
 /upgrading-checklist.html/
 /version.ent
+/README.txt
+/README.html
 *-1.html
 *.html.tar.gz
 *.pdf

=== removed file 'README.html'
--- README.html	2010-06-04 16:58:10 +0000
+++ README.html	1970-01-01 00:00:00 +0000
@@ -1,678 +0,0 @@
-<?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>
-<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="2010-06-04 09:42:57 PDT"/>
-<meta name="author" content="Manoj Srivastava And Russ Allbery"/>
-<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: black;
-   background-color: white;
-   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: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">
-<div id="org-div-home-and-up" 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>
-
-<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 <a href="./Process.html">Policy changes process</a>.
-</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 &lt;local-branch-name&gt;
-
-# edit files, but don't make changes to upgrading-checklist or debian/changelog
-git add &lt;files&gt;
-git commit
-# repeat as necessary
-
-# update your branch against the current master
-git checkout master
-git pull
-
-git checkout master
-git merge --no-commit &lt;local-branch-name&gt;
-git reset --hard HEAD;
-git checkout &lt;local-branch-name&gt;; 
-
-# If there are changes in master that make the branch not apply cleanly, there
-# should have been en error during the merge step above. If there was an
-# error, merge the master branch into the local branch, fix the conflicts, and
-# commit the new version of the local branch.
- : git merge master
-# Edit files to remove conflict
- : git commit -s 
-
-# Checkout the local branch, to create the patch to send to the policy
-git checkout &lt;local-branch-name&gt;
-dir=$(mktemp -d)
-git format-patch -o $dir -s master
-# check out the patches created in $dir
-git send-email --from <span style="font-style: italic;">"you &lt;<a href="mailto:your&#64;email">your&#64;email</a>&gt;"</span>             \
-               --to debian-policy@lists.debian.org   \
-               $dir/
-</pre>
-
-
-
-<p>
-&lt;local-branch-name&gt; 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="./Process.html">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="./Process.html">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&lt;number&gt;-&lt;user&gt;:: changes addressing bug &lt;number&gt;, shepherded by &lt;user&gt;
-</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&lt;number&gt;-&lt;user&gt; branch for the bug, where &lt;number&gt; is
-the bug number in the BTS and &lt;user&gt; 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
-
-git checkout master
-git merge --no-commit bug12345-rra
-git reset --hard HEAD;
-
-# If there are changes in master that make the branch not apply cleanly, there
-# should have been en error during the merge step above. If there was an
-# error, merge the master branch into the local branch, fix the conflicts, and
-# commit the new version of the local branch.
- : git checkout bug12345-rra
- : git merge master
-# Edit files to remove conflict
- : git commit -s 
-
-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">* &lt;document&gt;: &lt;brief change description&gt;
-  Wording: &lt;author of wording&gt;
-  Seconded: &lt;seconder&gt;
-  Seconded: &lt;seconder&gt;
-  Closes: &lt;bug numbers&gt;
-</pre>
-
-
-
-<p>
-For example:
-</p>
-
-
-<pre class="example">* Policy: better document version ranking and empty Debian revisions
-  Wording: Russ Allbery &lt;rra@debian.org&gt;
-  Seconded: Raphaël Hertzog &lt;hertzog@debian.org&gt;
-  Seconded: Manoj Srivastava &lt;srivasta@debian.org&gt;
-  Seconded: Guillem Jover &lt;guillem@debian.org&gt;
-  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="font-style: italic;">"$j"</span> != <span style="font-style: italic;">"master"</span> ]; then
-        git checkout $j &amp;&amp; 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 <a href="./Progress.html">Policy changes process</a> (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 And Russ Allbery
-</p>
-<p class="date"> Date: 2010-06-04 09:42:57 PDT</p>
-<p class="creator">HTML generated by org-mode 6.36c in emacs 23</p>
-</div>
-</div>
-</body>
-</html>

=== removed file 'README.txt'
--- README.txt	2010-06-04 16:58:10 +0000
+++ README.txt	1970-01-01 00:00:00 +0000
@@ -1,358 +0,0 @@
-                            Debian Policy
-                            =============
-
-Author: Manoj Srivastava And Russ Allbery
-Date: 2010-06-04 09:42:57 PDT
-
-
-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 [Policy changes process].
-
-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
-  
-  git checkout master
-  git merge --no-commit <local-branch-name>
-  git reset --hard HEAD;
-  git checkout <local-branch-name>; 
-  
-  # If there are changes in master that make the branch not apply cleanly, there
-  # should have been en error during the merge step above. If there was an
-  # error, merge the master branch into the local branch, fix the conflicts, and
-  # commit the new version of the local branch.
-   git merge master
-  # Edit files to remove conflict
-   git commit -s 
-  
-  # 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.
-
-
-[Policy changes process]: Process.txt
-
-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]: Process.txt
-[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]: Process.txt
-[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
-  
-  git checkout master
-  git merge --no-commit bug12345-rra
-  git reset --hard HEAD;
-  
-  # If there are changes in master that make the branch not apply cleanly, there
-  # should have been en error during the merge step above. If there was an
-  # error, merge the master branch into the local branch, fix the conflicts, and
-  # commit the new version of the local branch.
-   git checkout bug12345-rra
-   git merge master
-  # Edit files to remove conflict
-   git commit -s 
-  
-  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 [Policy changes process] (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.
-
-[Policy changes process]: ./Progress.org
-

