From: Manoj Srivastava Date: Thu, 16 Jun 2005 05:03:57 +0000 (+0000) Subject: Made the copyright look better X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=12ddf4d52dacf955ef56cc0115f2d03586f2497e;p=debian%2Fdebian-policy.git Made the copyright look better Author: srivasta Date: 1998/08/07 20:08:48 Made the copyright look better git-archimport-id: srivasta@debian.org--etch/debian-policy--devel--3.0--patch-4 --- diff --git a/proposal.sgml b/proposal.sgml index 19222a6..152c9ba 100644 --- a/proposal.sgml +++ b/proposal.sgml @@ -7,18 +7,23 @@ Manoj Srivastava srivasta@debian.org - $Revision: 1.4 $ + $Revision: 1.5 $ - - This document is copyright 1998 Manoj Srivastava. Anyone is - given permission to distribute this under the Freee software - foundations General Public Licence, Version 2, or any later - version, at your convenience. + Copyright © 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.

+

+ On Debian GNU/Linux systems, the complete text of the GNU + General Public License can be found in + `/usr/doc/copyright/GPL'.

- Introduction, and adminstrivia + Introduction, and Administrivia

This is a proposal for creating a process through which the Debian Policy documents are to be maintained and updated, it @@ -38,7 +43,7 @@

- People Seconding the proposal + People Seconding the Proposal

Well, since Michael Alan Dorman and Richard Braakman have volunteered to serve on the policy maintainer team, I think @@ -54,7 +59,7 @@ - Archives and personnel + Archives and Personnel The policy maintainers team

@@ -62,7 +67,7 @@ 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, not does it excersice editorial control, Policy is + policy, not 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 lists, which is how it was always done; so the group of @@ -93,17 +98,17 @@

The repository should contain all the packages under the - control of the team, and also should have anrea where the - weekly status document is kep; once the document is under + control of the team, and also should have an area where the + weekly status document is kept; once the document is under CVS, it should be a simple matter to script exporting the document out to a place where the web server can serve it, as well as create the weekly posting to - debian-poilcy and debian-devel mailing + debian-policy and debian-devel mailing lists. This document could also be kept under CVS then.

 - Procedures and processes + Procedures and Processes Proposing amendments to the Policy

@@ -115,7 +120,7 @@ policy amendment.

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

@@ -125,7 +130,7 @@

- Prevent frivoulous or ill concieved proposals from + Prevent frivolous or ill conceived proposals from wasting peoples time (If the proposal does not even convince two developers, surely this is not ready for inclusion in Policy?)

@@ -133,7 +138,7 @@

- Notifications and status reports + Notifications and Status Reports

Periodically, possibly weekly, a summary of current policy topics can be posted to the Developers mailing list, as @@ -151,7 +156,7 @@ - Deadlines for tabling discussions + Deadlines for Tabling Discussions

It has been observed in the past that discussions on the mailing list devolve into endless arguments. In order to get @@ -167,17 +172,17 @@

If a consensus is reached by the policy group, then the - maintianers shall enter the amendment into the Policy + maintainers shall enter the amendment into the Policy document, announce the inclusion in the periodic report, and release a new version.

- Extensions to deadlines? + Extensions to Deadlines?

If a deadline is approaching, and the discussion s 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 - extention could be granted. Care should be taken in + extension could be granted. Care should be taken in exercising this option, since abusing this would merely postpone closures.

@@ -187,7 +192,7 @@

Formerly, arriving at a consensus was the only way to amend Policy. That worked well when the Project was small, - however, we have aparently grown out of that phase, and even + 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 @@ -199,7 +204,7 @@ discussion period is near, then one is faced with a dilemma.

- Impasse on technical issues + Impasse on Technical Issues

On technical issues, popularity is a bad way of arriving at conclusions. Hopefully, the policy group would arrive @@ -209,7 +214,7 @@ may be consulted. This should be a rare occurrence.

- Non technical and subjective disagreements + 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 @@ -224,11 +229,11 @@ - Using the bug tracking system + Using the Bug Tracking System

A fascinating sub proposal has been that we use the bug tracking system to track policy amendments in progress. If - this is used, we may intiate discussions in the policy group + 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)

@@ -238,7 +243,7 @@ demoted to (forwarded?) wish list bugs. I like them being demoted to forwarded status, since the upstream authors (the policy mailing list) has already had a stab at them, and - they have been shelved until furhter notice.

+ they have been shelved until further notice.

I think that the Policy is critical enough for the project that any real flaws in the policy be automatically be deemed