For machines without a newer Emacs, this has no effect, but if a new
Emacs is present, the .txt and .html files shall be regenerated if the
org file is newer.
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
%.txt: %.org
$(EMACS) --batch -Q -l ./README-css.el -l org --visit $^ \
--funcall org-export-as-ascii >/dev/null 2>&1
%.txt: %.org
$(EMACS) --batch -Q -l ./README-css.el -l org --visit $^ \
--funcall org-export-as-ascii >/dev/null 2>&1
+ test "$@" != "README.txt" || \
+ perl -pli -e 's,./Process.org,Process.txt,g' $@
%.html: %.org
$(EMACS) --batch -Q -l ./README-css.el -l org --visit $^ \
--funcall org-export-as-html-batch >/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
<title>Debian Policy</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<meta name="generator" content="Org-mode"/>
<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="generated" content="2009-09-15 15:48:45 CDT"/>
+<meta name="author" content="Manoj Srivastava And Russ Allbery"/>
<meta name="description" content=""/>
<meta name="keywords" content=""/>
<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;
<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;
+ color: #000000;
+ background-color: LightSlateGray;
padding: 5pt;
font-family: "Courier New", courier, monospace;
font-size: 90%;
padding: 5pt;
font-family: "Courier New", courier, monospace;
font-size: 90%;
font-weight:bold; }
body {
font-weight:bold; }
body {
- color: LightSlateGray;
- background-color: #000000;
+ color: DarkSlateGrey;
+ background-color: gainsboro;
font-family: Palatino, "Palatino Linotype", "Hoefler Text", "Times New Roman", Times, Georgia, Utopia, serif;
}
.org-agenda-date { color: #87cefa; }
font-family: Palatino, "Palatino Linotype", "Hoefler Text", "Times New Roman", Times, Georgia, Utopia, serif;
}
.org-agenda-date { color: #87cefa; }
<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
<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.
+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
</p>
<p>
Once the wording for a change has been finalized, please send a patch
dir=$(mktemp -d)
git format-patch -o $dir -s master
# check out the patches created in $dir
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> \
+git send-email --from <span style="font-style: italic;">"you <<a href="mailto:your@email">your@email</a>>"</span> \
--to debian-policy@lists.debian.org \
$dir/
</pre>
--to debian-policy@lists.debian.org \
$dir/
</pre>
-<p>These documents are maintained using the <a href="http://wiki.debian.org/PolicyChangesProcess">Policy changes process</a>, and
+<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>
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>
(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
(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>
+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.
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.
<pre class="src src-Sh">for i in `git show-ref --heads | awk '{print $2}'`; do
j=$(basename $i)
<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
+ if [ <span style="font-style: italic;">"$j"</span> != <span style="font-style: italic;">"master"</span> ]; then
git checkout $j && git merge master
fi
done
git checkout $j && git merge master
fi
done
-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).
+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 the bug is not relevant to Policy and closing it.
</div>
</div>
<div id="postamble">
</div>
</div>
<div id="postamble">
-<p class="author"> Author: Manoj Srivastava
+<p class="author"> Author: Manoj Srivastava And Russ Allbery
<a href="mailto:srivasta@debian.org"><srivasta@debian.org></a>
</p>
<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="date"> Date: 2009-09-15 15:48:45 CDT</p>
<p class="creator">HTML generated by org-mode 6.30trans in emacs 23</p>
</div>
</div>
<p class="creator">HTML generated by org-mode 6.30trans in emacs 23</p>
</div>
</div>
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
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.
+phase, see [[./Process.org][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
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
+ [[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 ]]
+ [[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
+These documents are maintained using the [[./Process.org][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]].
the current state of all change proposals is tracked using the
[[http://bugs.debian.org/src:debian-policy][debian-policy BTS]].
(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
(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]]
+the current Policy document. All of the steps of [[./Process.org][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.
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.
of bugs and set as a target resolving them completely before the next
Policy release. Resolving a bug means one of the following:
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).
++ Proposing new language to address the bug that's seconded and approved by
+ the readers of the Policy list following the [[./Progress.org][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
+ 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
Debian Policy
=============
Debian Policy
=============
-Author: Manoj Srivastava <srivasta@debian.org>
-Date: 2009-09-13 00:31:16 CDT
+Author: Manoj Srivastava And Russ Allbery <srivasta@debian.org>
+Date: 2009-09-15 15:48:35 CDT
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
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.
+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
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
use git format-patch and git send-email if you want, but usually it's
overkill.
use git format-patch and git send-email if you want, but usually it's
overkill.
+
+[Policy changes process]: Process.txt
+
[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
[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
+[Policy changes process]: Process.txt
[debian-policy BTS]: http://bugs.debian.org/src:debian-policy
Get involved
[debian-policy BTS]: http://bugs.debian.org/src:debian-policy
Get involved
[current open bugs]: http://bugs.debian.org/src:debian-policy
[debian-policy@lists.debian.org]: mailto:debian-policy@lists.debian.org
[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
+[Policy changes process]: Process.txt
[debian-policy@lists.debian.org ]: mailto:debian-policy@lists.debian.org
Maintenance procedures
[debian-policy@lists.debian.org ]: mailto:debian-policy@lists.debian.org
Maintenance procedures
of bugs and set as a target resolving them completely before the next
Policy release. Resolving a bug means one of the following:
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).
++ 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
+ 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
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.
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
+
-stamp-build: version.ent $(sanitycheck)
+stamp-build: version.ent $(sanitycheck) upgrading-checklist.html \
+ upgrading-checklist.txt README.txt README.html \
+ Process.txt Process.html
$(MAKE) $(SGML_FILES:=.sgml.validate) \
$(SGML_FILES:=.html.tar.gz) \
$(SGML_FILES:=-1.html) \
$(MAKE) $(SGML_FILES:=.sgml.validate) \
$(SGML_FILES:=.html.tar.gz) \
$(SGML_FILES:=-1.html) \