我的书签
添加书签
移除书签8.3. Current Process
Each suggested change goes through different states. These states are denoted through either usertags of the debian-policy@packages.debian.org user or, for moreinfo, patch, pending, and wontfix, regular tags.
The Policy delegates are responsible for managing the tags on bugs and will update tags as new bugs are submitted or as activity happens on bugs. All Debian Developers should feel free to add the seconded tag as described below. Other tags should be changed with the coordination of the Policy Team.
8.3.1. State A: More information required
The Policy delegates are unable to determine whether the bug is really a Policy matter, or judge that there are missing details that would prevent a fruitful discussion (and may result in a confused and unhelpful discussion).
Policy delegates ask the original submitter to provide the missing details. Others are asked to refrain from discussing whatever they take the issue to be, limiting their postings to attempts to supply the missing details.
What needs to happen next: Submitter (or someone else) provides the requested information within 30 days, or the bug is closed.
The majority of bugs will skip this stage.
8.3.2. 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.
What needs to happen next: Reach a conclusion and consensus in the discussion and make a final proposal for what should be changed (if anything), moving to the proposal tag.
8.3.3. State C: Proposal
A final proposal has emerged from the discussion, and there is a rough consensus on how to proceed to resolve the issue.
What needs to happen next: Provided that the rough consensus persists, develop a patch against the current Policy document with specific wording of the change. Often this is done in conjunction with the proposal, in which case one may skip this step and move directly to patch tag.
8.3.4. State D: 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.
What needs to happen next: The proposal needs to be reviewed and seconded. Any Debian developer who agrees with the change and the conclusion of rough consensus from the discussion should say so in the bug log by seconding the proposal.
8.3.5. State E: Seconded
The proposal is signed off on by N Debian Developers. To start with, we’re going with N=3, meaning that if three Debian Developers agree, not just with the proposal but with the conclusion that it reflects consensus and addresses the original issue – it is considered eligible for inclusion in the next version of Policy. Since Policy is partly a technical project governance method, one must be a Debian Developer to formally second, although review and discussion is welcome from anyone. Once this tag has been applied, the bug is waiting for a Policy team member to apply the patch to the package repository.
What needs to happen next: A Policy maintainer does the final review and confirmation, and then applies the patch for the next Policy release.
This tag is not used very much because normally a Policy maintainer applies the patch and moves the proposal to the next state once enough seconds are reached.
8.3.6. State F: 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.
What needs to happen next: The bug is now in the waiting queue for the next Policy release, and there’s nothing left to do except for upload a new version of Policy.
8.3.7. State G: Reject
Rejected proposals. The standard wontfix is used for this state. Normally, bugs in this state will not remain open (excepting stalled); 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 proceeds.
We may use one of the following tags here. It’s not clear whether we need more tags for this stage.
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
Consensus on a proposal was not forthcoming, and the bug is to be closed. Those wishing to restart discussion should open a new bug, but only if they have a concrete new change proposal.
stalled
Consensus on a proposal was not forthcoming. However, the bug should be kept open, as a form of documentation, and to minimise the number of duplicate filings.
What may need to happen next: The bug should be closed once a final resolution is reached (excepting stalled), or retagged to an appropriate state if that final resolution reverses the decision to reject the proposal.
