[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


<!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
      <title>Updating Debian Policy documents</title>
	<name>Manoj Srivastava</name>
      <version>$Revision: 1.8 $</version>
	<copyrightsummary>Copyright &#169; 1998 by Manoj Srivastava. 
	  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>
	  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>
	This document describes the current practice followed in updating
	Debian Policy documents.
	<em>In the following, the term developer refers to registered
	  Debian developers.</em>
      <p>A copy of this document should also be found at <url
      <heading>Archives and Personnel</heading>
	<heading>The policy maintainers team</heading>
	  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.
	  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
	  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.
	<heading>The CVS Repository</heading>
	  The policy documents reside in a repository on
	  <tt>cvs.debian.org</tt>.  Only the 
	  policy maintainer team has write access to it. 
	  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>
      <heading>Procedures and Processes</heading>
	<heading>Proposing amendments to the Policy</heading>
	  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''.
	  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.
	  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.
	  <heading>Notifications and Status Reports</heading>
	    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>
	    Amendments to policy that have been accepted by the policy
	    group shall also be part of the notification.
	<heading>Deadlines for Tabling Discussions</heading>
	  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.
	  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>
	  <heading>Extensions to Deadlines?</heading>
	    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.
	<heading>Deadlock resolution</heading>
	  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.
	  <heading>Impasse on Technical Issues</heading>
	    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>
	  <heading>Non Technical and Subjective Disagreements</heading>
	    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>
	    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,
	<heading>Using the Bug Tracking System</heading>
	  The BTS serverities are used in the following manner.
	    <tag>Issue raised</tag>
		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.
		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. 
		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
		if the amendment is accepted, the bug is marked
		forwarded and retitled "[ACCEPTED DD/MM/YYY]...".
		if the amendment is closed, it is retitled as
		"[REJECTED  DD/MM/YYY] ..." and closed
		When the proposal is actually integrated into Policy
		and uploaded and moved into the archive, the bug is
	  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>

Reply to: