File: //usr/share/doc/debian-policy/policy.html/ap-process.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.17.1: http://docutils.sourceforge.net/" />
<title>8. Debian Policy changes process — Debian Policy Manual v4.6.0.1</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css" />
<link rel="stylesheet" type="text/css" href="_static/nature.css" />
<script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
<script src="_static/jquery.js"></script>
<script src="_static/underscore.js"></script>
<script src="_static/doctools.js"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="9. Maintainer script flowcharts" href="ap-flowcharts.html" />
<link rel="prev" title="7. Diversions - overriding a package’s version of a file (from old Packaging Manual)" href="ap-pkg-diversions.html" />
</head><body>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="ap-flowcharts.html" title="9. Maintainer script flowcharts"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="ap-pkg-diversions.html" title="7. Diversions - overriding a package’s version of a file (from old Packaging Manual)"
accesskey="P">previous</a> |</li>
<li class="nav-item nav-item-0"><a href="index.html">Debian Policy Manual v4.6.0.1</a> »</li>
<li class="nav-item nav-item-this"><a href=""><span class="section-number">8. </span>Debian Policy changes process</a></li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="debian-policy-changes-process">
<h1><span class="section-number">8. </span>Debian Policy changes process<a class="headerlink" href="#debian-policy-changes-process" title="Permalink to this headline">¶</a></h1>
<section id="introduction">
<span id="process-introduction"></span><h2><span class="section-number">8.1. </span>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
<p>To introduce a change in the current Debian Policy, the change proposal
has to go through a certain process. <a class="footnote-reference brackets" href="#id8" id="id1">1</a></p>
</section>
<section id="change-goals">
<span id="process-change-goals"></span><h2><span class="section-number">8.2. </span>Change Goals<a class="headerlink" href="#change-goals" title="Permalink to this headline">¶</a></h2>
<ul class="simple">
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>The change has to be reviewed in depth, in the open, where any one
may contribute; a publicly accessible, archived, open mailing list.</p></li>
<li><p>Proposal should be addressed in a timely fashion.</p></li>
<li><p>Any domain experts should be consulted, since not every policy
mailing list subscriber is an expert on everything, including policy
maintainers.</p></li>
<li><p>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.</p></li>
<li><p>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?).</p></li>
</ul>
</section>
<section id="current-process">
<span id="process-current"></span><h2><span class="section-number">8.3. </span>Current Process<a class="headerlink" href="#current-process" title="Permalink to this headline">¶</a></h2>
<p>Each suggested change goes through different states. These states are
denoted through either usertags of the
<a class="reference external" href="mailto:debian-policy%40packages.debian.org">debian-policy<span>@</span>packages<span>.</span>debian<span>.</span>org</a> user or, for <code class="docutils literal notranslate"><span class="pre">moreinfo</span></code>,
<code class="docutils literal notranslate"><span class="pre">patch</span></code>, <code class="docutils literal notranslate"><span class="pre">pending</span></code>, and <code class="docutils literal notranslate"><span class="pre">wontfix</span></code>, regular tags.</p>
<p><a class="reference external" href="https://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>
<section id="state-a-more-information-required">
<span id="state-a-moreinfo"></span><h3><span class="section-number">8.3.1. </span>State A: More information required<a class="headerlink" href="#state-a-more-information-required" title="Permalink to this headline">¶</a></h3>
<p>The Policy delegates are unable to determine whether the bug is really
a Policy matter, or judge that there are missing details that would
prevent a fruitful discussion (and may result in a confused and
unhelpful discussion).</p>
<p>Policy delegates ask the original submitter to provide the missing
details. Others are asked to refrain from discussing whatever they
take the issue to be, limiting their postings to attempts to supply
the missing details.</p>
<p><a class="reference external" href="https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=moreinfo">TAG: moreinfo</a></p>
<p>What needs to happen next: Submitter (or someone else) provides the
requested information within 30 days, or the bug is closed.</p>
<p>The majority of bugs will skip this stage.</p>
</section>
<section id="state-b-discussion">
<span id="id2"></span><h3><span class="section-number">8.3.2. </span>State B: Discussion<a class="headerlink" href="#state-b-discussion" title="Permalink to this headline">¶</a></h3>
<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.</p>
<p><a class="reference external" href="https://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>
</section>
<section id="state-c-proposal">
<span id="id3"></span><h3><span class="section-number">8.3.3. </span>State C: Proposal<a class="headerlink" href="#state-c-proposal" title="Permalink to this headline">¶</a></h3>
<p>A final proposal has emerged from the discussion, and there is a rough
consensus on how to proceed to resolve the issue.</p>
<p><a class="reference external" href="https://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>
</section>
<section id="state-d-wording-proposed">
<span id="id4"></span><h3><span class="section-number">8.3.4. </span>State D: Wording proposed<a class="headerlink" href="#state-d-wording-proposed" title="Permalink to this headline">¶</a></h3>
<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.</p>
<p><a class="reference external" href="https://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>
</section>
<section id="state-e-seconded">
<span id="id5"></span><h3><span class="section-number">8.3.5. </span>State E: Seconded<a class="headerlink" href="#state-e-seconded" title="Permalink to this headline">¶</a></h3>
<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.</p>
<p><a class="reference external" href="https://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>
</section>
<section id="state-f-accepted">
<span id="id6"></span><h3><span class="section-number">8.3.6. </span>State F: Accepted<a class="headerlink" href="#state-f-accepted" title="Permalink to this headline">¶</a></h3>
<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.</p>
<p><a class="reference external" href="https://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>
</section>
<section id="state-g-reject">
<span id="id7"></span><h3><span class="section-number">8.3.7. </span>State G: Reject<a class="headerlink" href="#state-g-reject" title="Permalink to this headline">¶</a></h3>
<p>Rejected proposals. The standard wontfix is used for this state.
Normally, bugs in this state will not remain open (excepting
<strong>stalled</strong>); 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.</p>
<p><a class="reference external" href="https://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. It’s not clear whether we
need more tags for this stage.</p>
<dl class="simple">
<dt><strong>dubious</strong></dt><dd><p>Not a policy matter</p>
</dd>
<dt><strong>ctte</strong></dt><dd><p>Referred to the Technical Committee (tech-ctte)</p>
</dd>
<dt><strong>devel</strong></dt><dd><p>Referred to the developer body</p>
</dd>
<dt><strong>delegate</strong></dt><dd><p>Rejected by a Policy delegate</p>
</dd>
<dt><strong>obsolete</strong></dt><dd><p>Consensus on a proposal was not forthcoming, and the bug is to be
closed. Those wishing to restart discussion should open a new
bug, but only if they have a concrete new change proposal.</p>
</dd>
<dt><strong>stalled</strong></dt><dd><p>Consensus on a proposal was not forthcoming. However, the bug
should be kept open, as a form of documentation, and to minimise
the number of duplicate filings.</p>
</dd>
</dl>
<p>What may need to happen next: The bug should be closed once a final
resolution is reached (excepting <strong>stalled</strong>), or retagged to an
appropriate state if that final resolution reverses the decision to
reject the proposal.</p>
</section>
</section>
<section id="other-tags">
<span id="process-other-tags"></span><h2><span class="section-number">8.4. </span>Other Tags<a class="headerlink" href="#other-tags" title="Permalink to this headline">¶</a></h2>
<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.</p>
<p><a class="reference external" href="https://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.</p>
<p><a class="reference external" href="https://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).</p>
<p><a class="reference external" href="https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging">TAG: packaging</a></p>
<dl class="footnote brackets">
<dt class="label" id="id8"><span class="brackets"><a class="fn-backref" href="#id1">1</a></span></dt>
<dd><p>This process was originally developed by Margarita Manterola, Clint
Adams, Russ Allbery and Manoj Srivastava. In 2017, Sean Whitton
deprecated the ‘issue’ usertag and added use of the ‘moreinfo’ tag,
after discussions at DebConf17.</p>
</dd>
</dl>
</section>
</section>
<div class="clearer"></div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h3><a href="index.html">Table of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">8. Debian Policy changes process</a><ul>
<li><a class="reference internal" href="#introduction">8.1. Introduction</a></li>
<li><a class="reference internal" href="#change-goals">8.2. Change Goals</a></li>
<li><a class="reference internal" href="#current-process">8.3. Current Process</a><ul>
<li><a class="reference internal" href="#state-a-more-information-required">8.3.1. State A: More information required</a></li>
<li><a class="reference internal" href="#state-b-discussion">8.3.2. State B: Discussion</a></li>
<li><a class="reference internal" href="#state-c-proposal">8.3.3. State C: Proposal</a></li>
<li><a class="reference internal" href="#state-d-wording-proposed">8.3.4. State D: Wording proposed</a></li>
<li><a class="reference internal" href="#state-e-seconded">8.3.5. State E: Seconded</a></li>
<li><a class="reference internal" href="#state-f-accepted">8.3.6. State F: Accepted</a></li>
<li><a class="reference internal" href="#state-g-reject">8.3.7. State G: Reject</a></li>
</ul>
</li>
<li><a class="reference internal" href="#other-tags">8.4. Other Tags</a></li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="ap-pkg-diversions.html"
title="previous chapter"><span class="section-number">7. </span>Diversions - overriding a package’s version of a file (from old Packaging Manual)</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="ap-flowcharts.html"
title="next chapter"><span class="section-number">9. </span>Maintainer script flowcharts</a></p>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/ap-process.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</div>
<script>$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
>index</a></li>
<li class="right" >
<a href="ap-flowcharts.html" title="9. Maintainer script flowcharts"
>next</a> |</li>
<li class="right" >
<a href="ap-pkg-diversions.html" title="7. Diversions - overriding a package’s version of a file (from old Packaging Manual)"
>previous</a> |</li>
<li class="nav-item nav-item-0"><a href="index.html">Debian Policy Manual v4.6.0.1</a> »</li>
<li class="nav-item nav-item-this"><a href=""><span class="section-number">8. </span>Debian Policy changes process</a></li>
</ul>
</div>
<div class="footer" role="contentinfo">
Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 4.2.0.
</div>
</body>
</html>