Updating Debian Policy
On 6 Mar 2000, Manoj Srivastava wrote:
> >>"Steve" == Steve Robbins <steve@nyongwa.montreal.qc.ca> writes:
>
> >> Umm, we like to keep things informal around here. So that
> >> document kinda reflects the way things are done, without having the
> >> weight of policy.
>
> Steve> If so, I do humbly suggest it be written as a "best practices"
> Steve> document, and not a "proposal" document.
>
> Please send me your changes, and I'll gladly modify the
> document to suit.
Essentially, I suggest that the language be changed from the conditional
to the present tense, and all the `policy rationale' be dropped. I attach
my quick attempt to do so.
However, I am constrained by ignorance, so I hope that some old-timers
will peruse this with an eye to answering the following questions:
* The proposal talks about putting the policy documents into a CVS
repository with a team of 4-8 `maintainers'. I have written this as
implemented, but I'm not sure it is.
* A status document is mentioned. Does it exist? Is it exported to the
web as described?
* The document describes using the BTS for proposing amendments, and
indeed I see there are bugs filed against policy. I assume therefore
that this is the 'current' practice, and left those bits in. I don't
really know if all the bug titles ([PROPOSAL], [AMENDMENT], [ACCEPTED],
etc are really in use. I don't know if all the deadline, deadline
extension, and dispute resolution stuff is really in use.
And finally, the controversial question:
* Who can file a policy bug, anyway? I have heard from three people
about this recently. Two (one a developer) claiming that anyone can
file a bug, and one developer claiming that only registered developers
may file a bug. The language in this document is left vague on this
point. It needs to be fixed up either way.
Now, from my own selfish point of view, I can't see the hurt caused by a
non-developer making a policy proposal. To get adopted, a proposal needs
two seconds, and be non-controversial (i.e. rough consensus on
debian-policy). Isn't that enough to weed out `silly' policy changes?
Or the bar could simply be raised higher for non-developer proposals. It
was suggested that a non-developer needs three developer seconds, whereas
a developer requires only two seconds.
At any rate, this `policy-update' document should be edited by someone in
the know, to reflect the current practices.
-Steve
<!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
<debiandoc>
<book>
<titlepag>
<title>Updating Debian Policy documents</title>
<author>
<name>Manoj Srivastava</name>
<email>srivasta@debian.org</email>
</author>
<version>$Revision: 1.8 $</version>
<copyright>
<copyrightsummary>Copyright © 1998 by Manoj Srivastava.
</copyrightsummary>
<p>
You are given permission to redistribute this document
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2, or (at your option) any later version.</p>
<p>
On Debian GNU/Linux systems, the complete text of the GNU
General Public License can be found in
`<var>/usr/share/common-licenses/GPL</var>'. </p>
</copyright>
</titlepag>
<chapt>
<heading>Introduction</heading>
<p>
This document describes the current practice followed in updating
Debian Policy documents.
</p>
<p>
<em>In the following, the term developer refers to registered
Debian developers.</em>
</p>
<p>A copy of this document should also be found at <url
id="http://master.debian.org/%7Esrivasta/policy/";></p>
</chapt>
<chapt>
<heading>Archives and Personnel</heading>
<sect>
<heading>The policy maintainers team</heading>
<p>
The policy maintainers team is a small group of people who have
access to the CVS repository for the Policy documents.
The team should have at least 4-5 people on
the job, preferably closer to 8, so that policy does not
languish when any maintainer goes missing.
</p>
<p>
This team is not the authors or editors of the documents,
but simply the maintainers. This group does not create
policy, nor does it exercise editorial control, Policy is
decided ``upstream''. The group that decides on policy is
the group of developers on the Debian-policy mailing
lists.
</p>
<p>
Since the policy maintainers have no special
powers, they are free to participate in policy discussions on
debian-policy. The archives of the list can be used
as a record of the action decided upon even if all
maintainers are away at some time.
</p>
</sect>
<sect>
<heading>The CVS Repository</heading>
<p>
The policy documents reside in a repository on
<tt>cvs.debian.org</tt>. Only the
policy maintainer team has write access to it.
</p>
<p>
The repository contains all the packages under the
control of the team, as well as a status document, updated weekly.
This status document should be exported to the web and a
weekly posting to the
<tt>debian-policy</tt> and <tt>debian-devel</tt> mailing
lists. It appears that this is not currently done.</p>
</sect>
</chapt>
<chapt>
<heading>Procedures and Processes</heading>
<sect>
<heading>Proposing amendments to the Policy</heading>
<p>
Policy issues are to be raised in the policy group, or
by filing a wish-list bug against debian-policy.
If the initial discussion warrants it, any developer,
with at least two seconds can formally propose a
policy amendment. The proposing developer then
raises the severity to ``normal''.
</p>
<p>
The whole discussion process is meant to be light weight. If
you wish the proposals to be amended, talk to the proposer,
and get the amendment in. Or, post an alternative, and
let the group decide which one is better.
</p>
<p>
If the process gets very contentious, and needs something
like votes on amendments and withdrawal of proposal, then
this is not the correct forum for this, and the procedures
outlined in the constitution should be followed. Note that
only non-technical issues can be resolved using the general
resolution protocol; technical issues would hopefully be
resolved in the group itself, or the technical committee can
be called upon to render a decision.
</p>
<sect1>
<heading>Notifications and Status Reports</heading>
<p>
Periodically, possibly weekly, a summary of current policy
topics can be posted to the Developers mailing list, as
well as to the policy mailing list. Since the BTS is used
for keeping track of policy amendments, the list of
current amendments shall always be on the web.</p>
<p>
Amendments to policy that have been accepted by the policy
group shall also be part of the notification.
</p>
</sect1>
</sect>
<sect>
<heading>Deadlines for Tabling Discussions</heading>
<p>
It has been observed in the past that discussions on the
mailing list devolve into endless arguments. In order to get
away from the debating society aspect, at the time of the
formal proposal, a deadline can be set (probably by the
proposer, since they are likely to have an idea how
contentious the discussion is likely to be) for ending
discussion on the issue, which should rarely be less than 10
days, and typically two weeks or so.
</p>
<p>
If a consensus is reached by the policy group, then the
maintainers shall enter the amendment into the Policy
document, announce the inclusion in the periodic report, and
release a new version.</p>
<sect1>
<heading>Extensions to Deadlines?</heading>
<p>
If a deadline is approaching, and the discussion is almost
concluded (in other words, it has not reached an impasse),
and the consensus on the policy group is that an extension
of a week would resolve the issues better, a one-time
extension could be granted. Care should be taken in
exercising this option, since abusing this would merely
postpone closures. Anything that is still not resolved is
too contentious not to be sent to the full set of
developers in a general resolution proposal.
</p>
</sect1>
</sect>
<sect>
<heading>Deadlock resolution</heading>
<p>
If a consensus is not reached, (or if someone submits a
formal objection to the proposal) and the end of the
discussion period is near, then one is faced with a dilemma.
</p>
<sect1>
<heading>Impasse on Technical Issues</heading>
<p>
On technical issues, popularity is a bad way of arriving
at conclusions. Hopefully, the policy group would arrive
at a consensus on their own. If that fails to happen, or
if there is a formal objection raised on the issue, and
the issue is a technical one, then the technical committee
may be consulted. This should be a rare occurrence. </p>
</sect1>
<sect1>
<heading>Non Technical and Subjective Disagreements</heading>
<p>
However, if the issue is non-technical and subjective,
then a vote of the developers may be taken.
A super-majority of 75% is needed to carry the
amendment through. Failing the super-majority, the issue
should be shelved. It may be re-submitted as a a fresh
proposal after a suitable cooling off period (which should
be no less than a month, typically three months being
desirable, unless there are significant new
developments). If the proposal has been entered into the BTS,
the bug will be demoted.</p>
<p>
If the issue raised is especially contentious, or is
deemed to be suitable for review by the full set of
developers, then four or more developers can call for a
hold on the proposal, and move to send the proposal to the
larger developer body as a General
Resolution. <strong>Note:</strong> The constitution may
have additional requirements for submitting a General
Resolution, for example, a minimum number of seconders,
etc.
</p>
</sect1>
</sect>
<sect>
<heading>Using the Bug Tracking System</heading>
<p>
The BTS serverities are used in the following manner.
<taglist>
<tag>Issue raised</tag>
<item>
<p>
wishlist bug opened in BTS, with a subject of
"[PROPOSED] ...". This is the pre discussion period,
when the idea is kicked around, and polished. There is
no preset time limit, but at some point, if it is
stalled, the bug should be closed.
</p>
</item>
<tag>Amendment</tag>
<item>
<p>
when a proposed issue becomes a formal amendment (when
it has acquired the required number of seconds), the
bug severity is raised to ``normal'' and the bug is
retitled to "[AMENDMENT DD/MM/YYY] ...". Actually it
might be better to close the proposal and reopen so
the bug date reflects when the clock starts ticking on
the bug.
</p>
<p>
This sets up the table for a discussion period,
normally 10 days to a month. At the end of the
discussion period, a proposal is either accepted, or
rejected.
</item>
<tag>Accepted</tag>
<item>
<p>
if the amendment is accepted, the bug is marked
forwarded and retitled "[ACCEPTED DD/MM/YYY]...".
</p>
</item>
<tag>Rejected</tag>
<item>
<p>
if the amendment is closed, it is retitled as
"[REJECTED DD/MM/YYY] ..." and closed
</p>
</item>
<tag>Incorporated</tag>
<item>
<p>
When the proposal is actually integrated into Policy
and uploaded and moved into the archive, the bug is
closed.
</p>
</item>
</taglist>
</p>
<p>
The Policy is critical enough for the project
that any real flaws in the policy be automatically be deemed
important bugs, unless they affect release management.</p>
</sect>
</chapt>
</book>
</debiandoc>
Reply to: