From f8904f6ce9f452cbb14ab70d3388262299ff9edb Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Mon, 28 Apr 2008 00:13:10 -0700 Subject: [PATCH] Remove the now-obsolete policy-process document --- debian-policy-process.desc | 15 -- debian/changelog | 1 + debian/rules | 4 +- policy-process.sgml | 347 ------------------------------------- 4 files changed, 3 insertions(+), 364 deletions(-) delete mode 100644 debian-policy-process.desc delete mode 100644 policy-process.sgml diff --git a/debian-policy-process.desc b/debian-policy-process.desc deleted file mode 100644 index 205c4aa..0000000 --- a/debian-policy-process.desc +++ /dev/null @@ -1,15 +0,0 @@ -Document: debian-policy-process -Title: Debian Policy Process Description -Author: The Debian Policy Mailing list -Abstract: This document describes how Debian Policy is developed. -Section: Debian - -Format: debiandoc-sgml -Files: /usr/share/doc/debian-policy/policy-process.sgml.gz - -Format: text -Files: /usr/share/doc/debian-policy/policy-process.txt.gz - -Format: HTML -Index: /usr/share/doc/debian-policy/policy-process.html/index.html -Files: /usr/share/doc/debian-policy/policy-process.html/*.html diff --git a/debian/changelog b/debian/changelog index 29dc6f4..052cd06 100644 --- a/debian/changelog +++ b/debian/changelog @@ -40,6 +40,7 @@ debian-policy (3.7.4.0) unstable; urgency=low Tautschnig (Closes: #422552). * Bug fix: "substvar reference moved from dpkg-source(1) to deb-substvars(5)", thanks to Ian Beckwith (Closes: #475731). + * Remove the now-obsolete policy-process document. * Add an md5sums control file. * Add Vcs-Browser and Vcs-Git control fields. * Remove build system support for FHS 2.1 and FSSTND, mostly commented out. diff --git a/debian/rules b/debian/rules index b17a442..e93ec32 100755 --- a/debian/rules +++ b/debian/rules @@ -43,9 +43,9 @@ LIBDIR := $(TMPTOP)/usr/share/doc-base sanitycheck := debian/rules policy.sgml -SGML_FILES := policy menu-policy mime-policy policy-process perl-policy +SGML_FILES := policy menu-policy mime-policy perl-policy DESC_FILES := debian-policy debian-menu-policy debian-perl-policy \ - debian-mime-policy debian-policy-process debconf-spec fhs + debian-mime-policy debconf-spec fhs # While we have two versions of the FHS installed in the source package, # we need to modify this to handle it. This is the easiest way to do it. diff --git a/policy-process.sgml b/policy-process.sgml deleted file mode 100644 index 8c433ff..0000000 --- a/policy-process.sgml +++ /dev/null @@ -1,347 +0,0 @@ - - - - - A mechanism for updating Debian Policy documents - - Manoj Srivastava - srivasta@debian.org - - $Revision: 1.7 $ - - Copyright © 2000 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.

-

- On Debian GNU/Linux systems, the complete text of the GNU - General Public License can be found in - /usr/share/common-licenses/GPL.

- - - - - Introduction, and Administrivia -

- This document documents the current practice followed in updating - Debian Policy documents. This mechanism has been designed for - dealing with policy changes that are light - weight and can be decided upon within the policy group, by - near consensus. In most day-to-day cases, the Policy group - should and must be able to conduct Policy discussions and - amendments without the intervention of the Technical Committee - or other Constitutional issues. Only in cases of extreme - dispute (formal objections) should the intervention of - Constitutional bodies come into play. In any other situation, - the Policy group should be able to conduct business - unfettered. A consequence of this goal is that formal - objections should not be used lightly, else this mechanism - shall be ineffective. -

-

- It should be noted that the team responsible for the task of - updating policy does not act as author or editor of Policy - itself, that is the task of the Debian Policy mailing list. -

-

- In the following, the term developer refers to registered - Debian developers. -

- - Guidelines for policy change proposals -

- Policy does not document all existing practice. It only - incorporates a minimal ruleset that is required for systems - integration (usually selecting one branch from several - equally viable technical options). It is not a best - practices document. -

-

- Policy changes under this procedure also should almost never - (unless directed by the tech-ctte, and perhaps the DPL) - cause a change that would make a significant chunk of - packages instantly buggy; for such changes, it is better to - implement a gradual transition plan, allowing for partial - upgrades (and perhaps using release goals as - motivators). Part of the rationale for this is common sense; - a global change, in the past, has taken time, and having - either a large number of RC bugs, or ignoring a large number - of bugs that would otherwise be RC seems silly; and, anyway, - there are concerns that the policy group does not really - have the power to change policy drastically. This is the - basis of the maxim policy shall not be used as a stick to beat - developers with. -

- -

- Nor does policy always document only existing - practices. What that oft misquoted statement refers to was - a part of a larger thesis that is meant to suggest that - policy is not the place for testing out design; if a - complicated technical proposal is to be made into policy, it - should be independently implemented, have all the kinks - worked out, and then have that working model be implemented - as policy. Having to change policy back and forth while a - design is being worked out needs be avoided. -

- - - - - - Archives and Personnel - - The policy maintainers team -

- The policy document is maintained by a group of people who have - access to the CVS repository for the Policy documents; - however, this set of people behave more like maintainers - rather than authors/editors. This group does not create - policy, nor does it exercise editorial control, Policy is - decided "upstream". The group that decides on policy should - be the group of developers on the debian-policy mailing - list, which is how it was always done; so the group of - policy maintainers have no real power over policy. -

-

- Since the policy maintainers have no special powers, there - is no restriction of their participation the discussion. It - is preferable to have at least 4-5 people on the job, - perhaps closer to 8, so that policy does not languish when - any maintainer goes missing (we do need vacations, you know, - once in a while), and since little creative power is vested - in the maintainers, we do not need a central control. And - the BTS can be used as a record of the action decided upon - even if all maintainers are away at some time. -

- - - The CVS Repository -

- There is a repository set up on cvs.debian.org for - this, and the people on the policy maintainer team have - write access to it. The Debian policy mailing list gets - copies of all the CVS commit notices. -

- - - - Procedures and Processes - - - Initiating discussions -

- Unlike before, when the policy editor gathered in issues - which, in his view, were candidates for inclusion in policy, - any one can raise an issue in the mailing list. It is - advisable, but by no means mandatory, that the proposer - tries an idea out on the mailing list, which can help flesh - out details rapidly, and test the sentiment and the - collective wisdom of the list. Discussion may be initiated by - any member of the list. -

-

- Once the proposer is satisfied that the proposal has merit - (with or without trying the waters on the list), the - proposer should file a wishlist bug against the - debian-policy package. This stage can be initiated by any - member of the list. -

- - - Creating a proposal - -

- Any Debian developer can create a proposal by retitling the - wishlist bug in the BTS to have the subject of the form - "[PROPOSED] ..." or - "[PROPOSAL] ...". (Note: The developer may - coalesce these steps into one by directly filing a - wishlist bug with the proper subject format). -

-

- 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. A - suggested time period is 6 months, since if the - proposal has had no action in that period, it is very likely - dead. If six months have actually passed, the bug should be - retitled "[OLD PROPOSAL] ...", and have the - severity set to fixed. The maintainers shall flush out old - proposals after a sufficiently long period of time has - elapsed (certainly more than a year or so after the initial - proposal). -

-

- Developers may second the issue by emailing a message - containing the text "seconded" to the proposal in the - BTS. Only registered Debian developers may second proposals. -

- - - Creating an Amendment -

- When a proposal in the BTS has acquired two seconds (apart - from the proposer), it becomes a formal amendment. The bug - severity is raised to "normal" and the bug is retitled to - "[AMENDMENT DD/MM/YYYY] ...". -

-

- The rationale behind the requirement for seconders is that - it would - -

- Encourage people to test the waters on the policy - mailing list, and this could help create an proposal - with a better chance of success

- - -

- Prevent frivolous or ill conceived proposals from - wasting people's time (if the proposal does not even - convince two developers, surely this is not ready for - inclusion in Policy?)

- - -

-

- The whole discussion process is meant to be lightweight; if - you wish the proposals to be amended, talk to the proposer, - and get the amendment in. Or else, 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. -

-

- This document is not supposed to supplant the processes - outlined in the constitution, nor is it intended to run - around them. -

- - - - Final disposition of the proposal - - An accepted amendment -

- If the amendment is accepted, the bug is marked - forwarded and retitled - "[ACCEPTED DD/MM/YYYY] ...". -

- - - An amendment that stalls or is rejected -

- If the amendment is stalls, or otherwise fails to pass, it - is retitled as "[REJECTED DD/MM/YYYY] ..." - and has its severity set to fixed. -

- - - - - - Deadlines for Tabling Discussions -

- It has been observed in the past that discussions on the - mailing list tend to 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. I hope that a hard - minimum period need not be set, and that the proposers would - be reasonable, and not set too short or too long a time for - discussion. -

-

- 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.

- - Extensions to Deadlines? -

- 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. -

- - - - Deadlock resolution -

- Formerly, arriving at a consensus was the only way to amend - Policy. That worked well when the Project was small, - however, we have apparently grown out of that phase, and even - the policy mailing list has grown more fractious than in the - days of yore. We now need a formal process of deadlock - resolution, and we need to recognize that on non-technical - issues a small minority should not always hold up deployment - of policy.

-

- 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. -

- - Impasse on Technical Issues -

- 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.

- - - Non Technical and Subjective Disagreements -

- However, if the issue is non-technical and subjective, - then a vote of the developers may be taken (USENET voting - software should be available all over the place, right?), - and 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). (Demote bug, if the BTS is being used)

-

- 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. Note: The constitution may - have additional requirements for submitting a General - Resolution, for example, a minimum number of seconders, - etc. -

- - - - - - - - - -- 2.39.2