This file is indexed.

/usr/share/doc/debian-policy/Process.html is in debian-policy 3.9.6.1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
<?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>
<!-- 2014-11-22 Sat 11:59 -->
<meta  http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta  name="generator" content="Org-mode" />
<meta  name="author" content="Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava" />
<style type="text/css">
 <!--/*--><![CDATA[/*><!--*/
  .title  { text-align: center; }
  .todo   { font-family: monospace; color: red; }
  .done   { color: green; }
  .tag    { background-color: #eee; font-family: monospace;
            padding: 2px; font-size: 80%; font-weight: normal; }
  .timestamp { color: #bebebe; }
  .timestamp-kwd { color: #5f9ea0; }
  .right  { margin-left: auto; margin-right: 0px;  text-align: right; }
  .left   { margin-left: 0px;  margin-right: auto; text-align: left; }
  .center { margin-left: auto; margin-right: auto; text-align: center; }
  .underline { text-decoration: underline; }
  #postamble p, #preamble p { font-size: 90%; margin: .2em; }
  p.verse { margin-left: 3%; }
  pre {
    border: 1px solid #ccc;
    box-shadow: 3px 3px 3px #eee;
    padding: 8pt;
    font-family: monospace;
    overflow: auto;
    margin: 1.2em;
  }
  pre.src {
    position: relative;
    overflow: visible;
    padding-top: 1.2em;
  }
  pre.src:before {
    display: none;
    position: absolute;
    background-color: white;
    top: -10px;
    right: 10px;
    padding: 3px;
    border: 1px solid black;
  }
  pre.src:hover:before { display: inline;}
  pre.src-sh:before    { content: 'sh'; }
  pre.src-bash:before  { content: 'sh'; }
  pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
  pre.src-R:before     { content: 'R'; }
  pre.src-perl:before  { content: 'Perl'; }
  pre.src-java:before  { content: 'Java'; }
  pre.src-sql:before   { content: 'SQL'; }

  table { border-collapse:collapse; }
  caption.t-above { caption-side: top; }
  caption.t-bottom { caption-side: bottom; }
  td, th { vertical-align:top;  }
  th.right  { text-align: center;  }
  th.left   { text-align: center;   }
  th.center { text-align: center; }
  td.right  { text-align: right;  }
  td.left   { text-align: left;   }
  td.center { text-align: center; }
  dt { font-weight: bold; }
  .footpara:nth-child(2) { display: inline; }
  .footpara { display: block; }
  .footdef  { margin-bottom: 1em; }
  .figure { padding: 1em; }
  .figure p { text-align: center; }
  .inlinetask {
    padding: 10px;
    border: 2px solid gray;
    margin: 10px;
    background: #ffffcc;
  }
  #org-div-home-and-up
   { text-align: right; font-size: 70%; white-space: nowrap; }
  textarea { overflow-x: auto; }
  .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; }
  /*]]>*/-->
</style>
<script type="text/javascript">
/*
@licstart  The following is the entire license notice for the
JavaScript code in this tag.

Copyright (C) 2012-2013 Free Software Foundation, Inc.

The JavaScript code in this tag is free software: you can
redistribute it and/or modify it under the terms of the GNU
General Public License (GNU GPL) as published by the Free Software
Foundation, either version 3 of the License, or (at your option)
any later version.  The code is distributed WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.  See the GNU GPL for more details.

As additional permission under GNU GPL version 3 section 7, you
may distribute non-source (e.g., minimized or compacted) forms of
that code without the copy of the GNU GPL normally required by
section 4, provided you include this license notice and a URL
through which recipients can access the Corresponding Source.


@licend  The above is the entire license notice
for the JavaScript code in this tag.
*/
<!--/*--><![CDATA[/*><!--*/
 function CodeHighlightOn(elem, id)
 {
   var target = document.getElementById(id);
   if(null != target) {
     elem.cacheClassElem = elem.className;
     elem.cacheClassTarget = target.className;
     target.className = "code-highlighted";
     elem.className   = "code-highlighted";
   }
 }
 function CodeHighlightOff(elem, id)
 {
   var target = document.getElementById(id);
   if(elem.cacheClassElem)
     elem.className = elem.cacheClassElem;
   if(elem.cacheClassTarget)
     target.className = elem.cacheClassTarget;
 }
/*]]>*///-->
</script>
</head>
<body>
<div id="content">
<h1 class="title">Debian Policy changes process</h1>
<p>
To introduce a change in the current DebianPolicy, the change proposal
has to go through a certain process.
</p>

<div id="outline-container-sec-1" class="outline-2">
<h2 id="sec-1">Change Goals</h2>
<div class="outline-text-2" id="text-1">
<ul class="org-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-sec-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-sec-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-sec-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-sec-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-sec-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-sec-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 &#x2013; 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-sec-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-sec-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 class="org-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-sec-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>
<div id="postamble" class="status">
<p class="author">Author: Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava</p>
<p class="date">Created: 2014-11-22 Sat 11:59</p>
<p class="creator"><a href="http://www.gnu.org/software/emacs/">Emacs</a> 24.4.1 (<a href="http://orgmode.org">Org</a> mode 8.2.10)</p>
<p class="validation"><a href="http://validator.w3.org/check?uri=referer">Validate</a></p>
</div>
</body>
</html>