<name>Manoj Srivastava</name>
<email>srivasta@debian.org</email>
</author>
- <version>$Revision: 1.6 $</version>
+ <version>$Revision: 1.9 $</version>
<copyright>
<copyrightsummary>Copyright © 1998 by Manoj Srivastava.
</copyrightsummary>
<p>
On Debian GNU/Linux systems, the complete text of the GNU
General Public License can be found in
- `<var>/usr/doc/copyright/GPL</var>'. </p>
+ `<var>/usr/share/common-licenses/GPL</var>'. </p>
</copyright>
</titlepag>
<chapt>
that is the task of the Debian Policy mailing list.
</p>
<p>
- It should also be pointed out that this proposal itself doess
- not call for the modificxation of the Policy documents
+ It should also be pointed out that this proposal itself does
+ not call for the modification of the Policy documents
themselves. I would rather not rush into anything as serious
as modification of the formal policy documents themselves, and
I suspect that we would learn and refine this process in
group. Traditionally, the policy group, under the aegis of the
Policy editor, worked on the basis of a consensus derived in
the group. This proposal merely removes the need of a
- dedicated policy editor, and passes the debian packages that
+ dedicated policy editor, and passes the Debian packages that
contain the policy into the hands of a few people who no
longer exercise editorial control, and, paying homage to our
growth, relaxes the requirement for a consensus.
as well as create the weekly posting to
<tt>debian-policy</tt> and <tt>debian-devel</tt> mailing
lists. This document could also be kept under CVS then.</p>
+ <p>
+ If possible, a separate mailing list (<tt>debian-policy-admin</tt>)
+ maybe created which gets copies of all the CVS commit
+ notices.
+ </p>
</sect>
</chapt>
<chapt>
let the group decide which one is better.
</p>
<p>
- If the process gets very contentous, and needs something
- like votes on amendments and withdrawl of proposal, then
+ 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
- outlied in the constitution should be followed.
+ 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>
<p>
- This document is not suppoed to supplant the processes
+ This document is not supposed to supplant the processes
outlined in the constitution, nor is it an end run around
them.
</p>
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. </p>
+ 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>
resolution, and we need to recognize that on non-technical
issues a small minority should not always hold up deployment
of policy.</p>
- <p>
- If the issue raised is especially contentous, 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>
<p>
If a consensus is not reached, (or if someone submits a
formal objection to the proposal) and the end of the
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)</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>
tracking system to track policy amendments in progress. If
this is used, we may initiate discussions in the policy
group by filing wish-list bugs (note: this should be open to
- anyone at all) This simplies how me manage and track open
- amendments and issues. I think both retitling and the
+ anyone at all) This simplifies how me manage and track open
+ amendments and issues. I think both re-titling and the
severity of the bugs can and should be used.</p>
<p>
<taglist>
<item>
<p>
wishlist bug opened in BTS, with a subject of
- "[PROPOSED] ..."
+ "[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. Only registered
+ Debian developers may formally create proposals.
</p>
- </item>
- <tag>Seconds</tag>
- <item>
<p>
developers may second the issue by emailing "seconded"
- to the BTS. (Issue: what if the so called seconder is
- not a registered Debian developer?)
+ to the BTS. Only registered Debian developers may
+ second proposals.
</p>
</item>
<tag>Amendment</tag>
<item>
<p>
- when a propsed issue becomes a formal amendment, the
+ 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; in which case the bug could simply be
- retitled "[AMENDMENT] ...".
+ 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, until it is actually integrated into Policy
- and uploaded and moved into the archive, at which time
- the bug is retitled "[ACCEPTED]..." and closed.
+ forwarded and retitled "[ACCEPTED DD/MM/YYY]...".
</p>
</item>
<tag>Rejected</tag>
<item>
<p>
if the amendment is closed, it is retitled as
- "[REJECTED] ..." and marked as closed
+ "[REJECTED DD/MM/YYY] ..." and closed
</p>
</item>
- <tag>Deadlocked</tag>
+ <tag>Incorporated</tag>
<item>
<p>
- if the amendment is deadlocked, it is marked as
- "[DEADLOCKED] ...",
+ When the proposal is actually integrated into Policy
+ and uploaded and moved into the archive, the bug is
+ closed.
</p>
</item>
</taglist>
projects / debian / debian-policy.git / blobdiff