+/Process.html
+/README.html
/body.tmp
/debconf_spec/debconf_specification.html
/debconf_spec/debconf_specification.txt.gz
mime-policy.sgml: version.ent
perl-policy.sgml: version.ent
-ifneq (,$(strip $(HAVE_ORG_EMACS)))
%.txt: %.org
$(EMACS) --batch -Q -l ./README-css.el -l org -l org-ascii --visit $^ \
--funcall org-export-as-ascii >/dev/null 2>&1
%.html: %.org
$(EMACS) --batch -Q -l ./README-css.el -l org --visit $^ \
--funcall org-export-as-html-batch >/dev/null 2>&1
-endif
%.validate: %
nsgmls -wall -gues $<
+++ /dev/null
-<?xml version="1.0" encoding="utf-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"
-lang="en" xml:lang="en">
-<head>
-<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="2010-06-04 09:41:24 PDT"/>
-<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: 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 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 C: 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 D: 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 E: 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 F: 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 G: 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
-</p>
-<p class="date"> Date: 2010-06-04 09:41:24 PDT</p>
-<p class="creator">HTML generated by org-mode 6.36c in emacs 23</p>
-</div>
-</div>
-</body>
-</html>
+++ /dev/null
- Debian Policy changes process
- =============================
-
-Author: Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava
-Date: 2010-06-04 09:41:23 PDT
-
-
-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 C: 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 D: 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 E: 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 F: 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 G: Reject
-================
-
-Rejected proposals. The standard wontfix is used for this
-state. Normally, bugs in this state will not remain open; instead, a
-Policy team member will close them with an explanation. The submitter
-may then appeal to the tech-ctte if they so desire. Alternately,
-issues appealed to the tech-ctte may remain open with this tag while
-that appeal proceeds.
-[TAG: wontfix]
-
-We may use one of the following tags here, but to date we have only
-used dubious and ctte. It's not clear whether we need more tags for
-this tage.
-
-*dubious*: Not a policy matter
-*ctte*: Referred to the Technical Committee (tech-ctte)
-*devel*: Referred to the developer body
-*delegate*: Rejected by a Policy delegate
-*obsolete*: The proposal timed out without a conclusion
-
-What needs to happen next: The bug should be closed once a final
-resolution is reached, or retagged to an appropriate state if that
-final resolution reverses the decision to reject the proposal.
-
-
-[TAG: wontfix]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=rejected
-
-Other Tags
-~~~~~~~~~~~
-
-All Policy bugs are additionally categorized by class of bug.
-
-The normative tag is used for bugs that make normative changes to
-Policy, meaning that the dictates of Policy will change in some
-fashion as part of the resolution of the bug if the proposal is
-accepted. The full process is followed for such bugs.
-[TAG: normative]
-
-The informative tag is used for bugs about wording issues, typos,
-informative footnotes, or other changes that do not affect the formal
-dictates of Policy, just the presentation. The same tags are used for
-these bugs for convenience, but the Policy maintainers may make
-informative changes without following the full process. Informative
-bugs fall under their discretion.
-[TAG: informative]
-
-The packaging tag is used for bugs about the packaging and build
-process of the debian-policy Debian package. These bugs do not follow
-the normal process and will not have the other tags except for pending
-and wontfix (used with their normal meanings).
-[TAG: packaging]
-
-[TAG: normative]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=normative
-[TAG: informative]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=informative
-[TAG: packaging]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging
-
+++ /dev/null
-<?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 <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 <span style="font-style: italic;">"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="./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<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
-
-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">* <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="font-style: italic;">"$j"</span> != <span style="font-style: italic;">"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 <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>
+++ /dev/null
- 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
-
-Indep in a package that builds only architecture-independent binary
packages), wrap it, and remove version restrictions that are older
than the version in oldstable.
+ * Add emacs23 to the build dependencies and remove the files generated
+ from org source from the revision control repository. Build and clean
+ files from org source unconditionally. Add Process.{txt,html} to the
+ list of files generated from org source. (Closes: #594274)
-- Russ Allbery <rra@debian.org> Thu, 12 Aug 2010 10:47:47 -0700
Bill Allombert <ballombe@debian.org>
Standards-Version: 3.9.0
Build-Depends: bsdmainutils, debiandoc-sgml (>= 1.1.47), docbook-dsssl,
- docbook-xml, groff, jade, links | elinks, pstoedit, sgml-data, texlive,
- texlive-latex-extra, tidy
+ docbook-xml, emacs23, groff, jade, links | elinks, pstoedit, sgml-data,
+ texlive, texlive-latex-extra, tidy
Vcs-Browser: http://git.debian.org/?p=dbnpolicy/policy.git
Vcs-Git: git://git.debian.org/git/dbnpolicy/policy.git
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))
-
+# Currently, emacs23 is required (xemacs is not sufficient).
+EMACS := emacs23
# Location of the source dir
SRCTOP := $(CURDIR)
policy.ps.gz policy.pdf.gz README.txt README.html \
Process.txt Process.html
+FILES_FROM_ORG := Process.html Process.txt README.txt README.html
+
# policy.{pdf,ps,tpt,txt} are generated files
FILES_TO_CLEAN = debian/files debian/buildinfo debian/substvars \
debian/postinst debian/prerm \
policy.pdf.gz policy.ps.gz \
debconf_specification.xml.tar.gz \
policy.pdf policy.ps policy.txt policy. \
- body.tmp head.tmp policy.tpt
-
-FILES_FROM_ORG := README.txt README.html
+ body.tmp head.tmp policy.tpt \
+ $(FILES_FROM_ORG)
STAMPS_TO_CLEAN := stamp-policy stamp-build
DIRS_TO_CLEAN := debian/tmp fhs $(SGML_FILES:=.html)
all build: stamp-build
-stamp-build: version.ent $(sanitycheck) README.txt README.html \
- Process.txt Process.html
+stamp-build: version.ent $(sanitycheck)
$(MAKE) $(SGML_FILES:=.sgml.validate) \
$(SGML_FILES:=.html.tar.gz) \
$(SGML_FILES:=-1.html) \
$(SGML_FILES:=.txt.gz) \
policy.ps.gz policy.pdf.gz
-ifneq (,$(strip $(HAVE_ORG_EMACS)))
$(MAKE) $(FILES_FROM_ORG)
-endif
$(MAKE) -C debconf_spec all
touch stamp-build
projects / debian / debian-policy.git / commitdiff