Debian Policy uses a formal procedure and a set of user tags to manage
the lifecycle of change proposals. For definitions of those tags and
proposal states and information about what the next step is for each
-phase, see PolicyChangesProcess.
+phase, see [[./Process.org][Policy changes process]].
Once the wording for a change has been finalized, please send a patch
against the current Git master branch to the bug report, if you're not
git checkout master
git pull
-# If there are changes in master that make the branch not apply cleanly:
- : git checkout -b temp master; git merge <local-branch-name>
-# If error, reset temp, merge master into local; else skip these three lines
- : git reset --hard HEAD;
- : git checkout <local-branch-name>;
+git checkout master
+git merge --no-commit <local-branch-name>
+git reset --hard HEAD;
+git checkout <local-branch-name>;
+
+# If there are changes in master that make the branch not apply cleanly, there
+# should have been en error during the merge step above. If there was an
+# error, merge the master branch into the local branch, fix the conflicts, and
+# commit the new version of the local branch.
: git merge master
-# get rid of the temp branch:
- : git branch -D temp
+# Edit files to remove conflict
+ : git commit -s
# Checkout the local branch, to create the patch to send to the policy
git checkout <local-branch-name>
In addition to the main technical manual, the team currently also maintains:
++ [[http://www.debian.org/doc/packaging-manuals/copyright-format/1.0][Machine-readable debian/copyright format]]
+ [[http://www.debian.org/doc/packaging-manuals/menu-policy/][Debian Menu sub-policy]]
+ [[http://www.debian.org/doc/packaging-manuals/perl-policy/][Debian Perl Policy]]
+ [[http://www.debian.org/doc/packaging-manuals/mime-policy/][Debian MIME support sub-policy]]
+ [[http://www.debian.org/doc/packaging-manuals/debconf_specification.html][Debconf Specification]]
+ [[http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt][Authoritative list of virtual package names ]]
-These documents are maintained using the [[http://wiki.debian.org/PolicyChangesProcess][Policy changes process]], and
+These documents are maintained using the [[./Process.org][Policy changes process]], and
the current state of all change proposals is tracked using the
[[http://bugs.debian.org/src:debian-policy][debian-policy BTS]].
(particularly from experts in the area being discussed), possibly
raising the issue on other mailing lists, proposing or getting other
people to propose specific wording changes, and writing diffs against
-the current Policy document. All of the steps of [[http://wiki.debian.org/PolicyChangesProcess][Policy changes process]]
+the current Policy document. All of the steps of [[./Process.org][Policy changes process]]
can be done by people other than Policy team members except
the final acceptance steps and almost every change can be worked on
independently, so there's a lot of opportunity for people to help.
# update your local master branch
git checkout master
git pull
-# If there are changes in master that make the branch not apply cleanly:
-: git checkout -b temp master; git merge bug12345-rra
-# If error;
-: git reset --hard HEAD;
-: git checkout bug12345-rra; git branch -D temp
-: git merge master
+
+git checkout master
+git merge --no-commit bug12345-rra
+git reset --hard HEAD;
+
+# If there are changes in master that make the branch not apply cleanly, there
+# should have been en error during the merge step above. If there was an
+# error, merge the master branch into the local branch, fix the conflicts, and
+# commit the new version of the local branch.
+ : git checkout bug12345-rra
+ : git merge master
+# Edit files to remove conflict
+ : git commit -s
+
git checkout master
git merge bug12345-rra
# edit debian/changelog and upgrading-checklist.html
of bugs and set as a target resolving them completely before the next
Policy release. Resolving a bug means one of the following:
-+ Proposing new language to address the bug that's seconded and
- approved by the readers of the Policy list following the
- PolicyChangesProcess (or that's accepted by one of the Policy
- delegates if the change isn't normative; i.e., doesn't change the
- technical meaning of the document).
++ Proposing new language to address the bug that's seconded and approved by
+ the readers of the Policy list following the [[./Progress.org][Policy changes process]] (or
+ that's accepted by one of the Policy delegates if the change isn't
+ normative; i.e., doesn't change the technical meaning of the document).
+ Determining that the bug is not relevant to Policy and closing it.
+ Determining that either there is no consensus that the bug indicates
a problem, that the solutions that we can currently come up with are