Differences between revisions 4 and 5
Revision 4 as of 2008-03-15 13:42:45
Size: 4585
Editor: ClintAdams
Comment: missing bracket
Revision 5 as of 2008-03-18 03:25:56
Size: 5822
Editor: RussAllbery
Comment: Update for the current bug categories.
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
== Change Goals == = Change Goals =
Line 5: Line 5:
 * The change should be technically correct, and consistent with the
rest of the policy document. This means no legislating the value of π.
This also means that the proposed solution be known to work;
iterative design processes do not belong in policy.
 * The change should not be too disruptive; if very many packages
become instantly buggy, then instead there should be a transition
plan. Exceptions should be rare (only if the current state is
really untenable), and probably blessed by the TC.
 * The change has to be reviewed in depth, in the open, where any one
 may contribute; a publicly accessible, archived, open mailing list.
 * The change should be technically correct, and consistent with the rest of the policy document. This means no legislating the value of π.  This also means that the proposed solution be known to work; iterative design processes do not belong in policy.

* The change should not be too disruptive; if very many packages become instantly buggy, then instead there should be a transition plan. Exceptions should be rare (only if the current state is really untenable), and probably blessed by the TC.

* The change has to be reviewed in depth, in the open, where any one may contribute; a publicly accessible, archived, open mailing list.
Line 16: Line 12:
 * Any domain experts should be consulted, since not every
 policy mailing list subscriber is an expert on everything,
 including policy maintainers.
 * The goal is rough consensus on the change, which should not be hard
 if the matter is technical. Technical issues where there is no
 agreement should be referred to the TC; non-technical issues should
 be referred to the whole developer body, and perhaps general
 resolutions lie down that path.
 * Package maintainers whose packages may be impacted should have
 access to policy change proposals, even if they do not subscribe to
 policy mailing lists (policy gazette?).
Line 28: Line 13:
== Possible States ==  * Any domain experts should be consulted, since not every policy mailing list subscriber is an expert on everything, including policy maintainers.
Line 30: Line 15:
Each suggested change goes through different states. These states are denoted through usertags of the debian-policy@packages.debian.org user. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=debian-policy@packages.debian.org&ordering=policy&pend-exc=done Current list of bugs]  * The goal is rough consensus on the change, which should not be hard if the matter is technical. Technical issues where there is no agreement should be referred to the TC; non-technical issues should be referred to the whole developer body, and perhaps general resolutions lie down that path.
 
 * Package maintainers whose packages may be impacted should have access to policy change proposals, even if they do not subscribe to policy mailing lists (policy gazette?).

= Possible States =

Each suggested change goes through different states. These states are denoted through usertags of the debian-policy@packages.debian.org user. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done Current list of bugs]
Line 36: Line 27:
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=debian-policy@packages.debian.org&ordering=policy&pend-exc=done&tag=issue  TAG: issue] [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&tag=issue TAG: issue]
Line 41: Line 32:
There should be a clear time limit to this stage.
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=debian-policy@packages.debian.org&ordering=policy&pend-exc=done;tag=discussion TAG: discussion]

=== State C: Solicit advice [Optional] ===

Solicit domain expert input
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=debian-policy@packages.debian.org&ordering=policy&pend-exc=done;tag=opinion TAG: opinion]
There should be a clear time limit to this stage, but as yet we have not set one.
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=discussion TAG: discussion]
Line 52: Line 38:
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=debian-policy@packages.debian.org&ordering=policy&pend-exc=done;tag=proposal TAG: proposal] [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=proposal TAG: proposal]
Line 56: Line 42:
Close to a working solution. Create policy language, rationale, test, and publish.
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=debian-policy@packages.debian.org&ordering=policy&pend-exc=done;tag=wording TAG: wording]
A patch against the Policy document reflecting the consensus has been created and is waiting for formal seconds. The standard patch tag is used for this state, since it's essentially equivalent to the standard meaning of that tag.
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch TAG: patch]
Line 61: Line 47:
The proposal is signed off on by N developers, N=3? (stages D and E may be reversed) Final discussions start; input from affected developers.
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=debian-policy@packages.debian.org&ordering=policy&pend-exc=done;tag=seconded TAG: seconded]
The proposal is signed off on by N developers, N=3? Final discussions start; input from affected developers. By the time this tag has been applied, the bug is waiting for a Policy team member to apply the patch to the package repository.
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=seconded TAG: seconded]
Line 66: Line 52:
Change accepted, will be in next upload.
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=debian-policy@packages.debian.org&ordering=policy&pend-exc=done;tag=accepted TAG: accepted]
Change accepted, will be in next upload. The standard pending tag is used for this state since it matches the regular meaning of pending.
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=accepted TAG: accepted]
Line 71: Line 57:
Rejected proposals.
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=debian-policy@packages.debian.org&ordering=policy&pend-exc=done;tag=rejected TAG: rejected]
Rejected proposals. The standard wontfix is used for this state. Normally, bugs in this state will not remain open; instead, a Policy team member will close them with an explanation. The submitter may then appeal to the tech-ctte if they so desire. Alternately, issues appealed to the tech-ctte may remain open with this tag while that appeal procedes.
[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=rejected TAG: rejected]
Line 74: Line 60:
These can be one of:
==== State H1: dubious ====
  Not a policy matter
  [TAG: dubious]
==== State H2: Ctte ====
   Referred to TC
   [TAG: ctte]
==== State H3: Devel ====
   Referred to developer body
   [TAG: devel]
==== State H4: Delegate ====
   Rejected by delegates (sent by default to TC)
   [TAG: delegate]
==== State H5: Timeout ====
   Timed out, no policy created.
   [TAG: obsolete]
We may use one of the following tags here, but to date we have not done so. It's not clear whether we need more tags for this tage.

 dubious: Not a policy matter
 ctte: Referred to the Technical Committee (tech-ctte)
 devel: Referred to the developer body
 delegate: Rejected by a Policy delegate
 obsolete: The proposal timed out without a conclusion

= Other Tags =

All Policy bugs are additionally categorized by class of bug.

The normative tag is used for bugs that make normative changes to Policy, meaning that the dictates of Policy will change in some fashion as part of the resolution of the bug if the proposal is accepted. The full process is followed for such bugs. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=normative TAG: normative]

The informative tag is used for bugs about wording issues, typos, informative footnotes, or other changes that do not affect the formal dictates of Policy, just the presentation. The same tags are used for these bugs for convenience, but the Policy maintainers may make informative changes without following the full process. Informative bugs fall under their discretion. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=informative TAG: normative]

The packaging tag is used for bugs about the packaging and build process of the debian-policy Debian package. These bugs do not follow the normal process and will not have the other tags except for pending and wontfix (used with their normal meanings). [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging TAG: packaging]

To introduce a change in the current DebianPolicy, the change proposal has to go through a certain process.

Change Goals

  • The change should be technically correct, and consistent with the rest of the policy document. This means no legislating the value of π. This also means that the proposed solution be known to work; iterative design processes do not belong in policy.
  • The change should not be too disruptive; if very many packages become instantly buggy, then instead there should be a transition plan. Exceptions should be rare (only if the current state is really untenable), and probably blessed by the TC.
  • The change has to be reviewed in depth, in the open, where any one may contribute; a publicly accessible, archived, open mailing list.
  • Proposal should be addressed in a timely fashion.
  • Any domain experts should be consulted, since not every policy mailing list subscriber is an expert on everything, including policy maintainers.
  • The goal is rough consensus on the change, which should not be hard if the matter is technical. Technical issues where there is no agreement should be referred to the TC; non-technical issues should be referred to the whole developer body, and perhaps general resolutions lie down that path.
  • Package maintainers whose packages may be impacted should have access to policy change proposals, even if they do not subscribe to policy mailing lists (policy gazette?).

Possible States

Each suggested change goes through different states. These states are denoted through usertags of the debian-policy@packages.debian.org user. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done Current list of bugs]

State A: Issue raised

Detect need, like gaps/flaws in current policy, or a new rule should be added. Any user or developer may start this step. There is a decision point here, not all issues are in scope of policy. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&tag=issue TAG: issue]

State B: Discussion

Discuss remedy. Alternate proposals. Discussion guided by delegates. There should be a clear time limit to this stage, but as yet we have not set one. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=discussion TAG: discussion]

State D: Proposal

A final proposal has emerged from the discussion, and there is a rough consensus on how to proceed to resolve the issue. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=proposal TAG: proposal]

State E: Wording proposed

A patch against the Policy document reflecting the consensus has been created and is waiting for formal seconds. The standard patch tag is used for this state, since it's essentially equivalent to the standard meaning of that tag. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch TAG: patch]

State F: Seconded

The proposal is signed off on by N developers, N=3? Final discussions start; input from affected developers. By the time this tag has been applied, the bug is waiting for a Policy team member to apply the patch to the package repository. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=seconded TAG: seconded]

State G: Accepted

Change accepted, will be in next upload. The standard pending tag is used for this state since it matches the regular meaning of pending. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=accepted TAG: accepted]

State H: Reject

Rejected proposals. The standard wontfix is used for this state. Normally, bugs in this state will not remain open; instead, a Policy team member will close them with an explanation. The submitter may then appeal to the tech-ctte if they so desire. Alternately, issues appealed to the tech-ctte may remain open with this tag while that appeal procedes. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=rejected TAG: rejected]

We may use one of the following tags here, but to date we have not done so. It's not clear whether we need more tags for this tage.

  • dubious: Not a policy matter ctte: Referred to the Technical Committee (tech-ctte) devel: Referred to the developer body delegate: Rejected by a Policy delegate obsolete: The proposal timed out without a conclusion

Other Tags

All Policy bugs are additionally categorized by class of bug.

The normative tag is used for bugs that make normative changes to Policy, meaning that the dictates of Policy will change in some fashion as part of the resolution of the bug if the proposal is accepted. The full process is followed for such bugs. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=normative TAG: normative]

The informative tag is used for bugs about wording issues, typos, informative footnotes, or other changes that do not affect the formal dictates of Policy, just the presentation. The same tags are used for these bugs for convenience, but the Policy maintainers may make informative changes without following the full process. Informative bugs fall under their discretion. [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=informative TAG: normative]

The packaging tag is used for bugs about the packaging and build process of the debian-policy Debian package. These bugs do not follow the normal process and will not have the other tags except for pending and wontfix (used with their normal meanings). [http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging TAG: packaging]


CategoryDebianDevelopment