General Status ============== Debian Policy work has largely been on hold for the past few months, partly due to the release freeze but mostly due to lack of time and resources. Policy 3.8.1 is in preparation and already includes 12 bug fixes, 7 normative (affecting the requirements set by Policy rather than the wording, presentation, or supporting documentation). The current plan is to release Policy 3.8.1 very shortly after the lenny release so that maintainers doing their first squeeze uploads can update to the new version of Policy at the same time. There are currently 128 open bugs against Debian Policy, most of which are not being actively pursued. Team Membership =============== Manoj Srivastava has stepped down as a Policy delegate [1]. Manoj's first upload of the debian-policy package was in October of 1998. He has spent over ten years guiding and improving Debian's technical policy, and Debian is much better for his efforts. With his resignation, there is only one currently active Policy delegate. This is obviously insufficient to stay on top of incoming bug reports, let alone to make significant improvements in Policy, reduce the bug backlog, or proactively resolve known issues. More Policy team members are badly needed. More people working on Policy in general are needed, including simply participating in discussions on the mailing lists and evaluating proposals, but we also need experienced Debian developers who have the time and background required to be full Policy delegates. The responsibilities of a Policy team member are: 1. Shepherd debian-policy bugs through to a resolution following the Policy changes process [2]. Anyone can do this, but Policy delegates have the final responsibility to try to see that every bug receives some attention. 2. Make decisions to accept seconded wording or reject proposals at the final stages of the Policy changes process. 3. Edit the Debian Policy document and its associated sub-policies for consistent wording, fixing typos and mistakes, and so forth. Hopefully also help with converting or rewriting it over time into a newer, more standardized and more formalized format. 4. Maintain the debian-policy package as a package, fix packaging problems, and upload new versions. Almost anyone with some experience with Debian packaging and technical experience with what works and what doesn't in package integration can usefully participate on the debian-policy mailing list. A Policy delegate should additionally have reasonably wide-ranging technical experience, a sense of where it is reasonable to standardize a practice and where it's premature, and the ability to pursue a consensus solution to a problem through multiple iterations. If you are interested in volunteering to be a Policy delegate, please contact Russ Allbery <rra@debian.org> and Steve McIntyre in his capacity as Debian Project Leader <leader@debian.org>. Policy Process ============== Currently, there are a large number of open bugs against debian-policy, many of which have been lingering there for many years. There are technical packages for which it's reasonable to carry wishlist bugs for features until someone has a chance to implement them. This isn't the case for Policy. We should strive for being able to discuss and make a clear decision about a change proposal in a reasonable length of time. For each release of Policy, the Policy delegates will try to take a set of open issues and shepherd them through to resolution in that release. Anyone can help with this process, and help would be greatly appreciated. On the Policy wiki page [3] are details for how this process works. Now is an excellent time for those who aren't busy with the lenny release to help resolve relatively minor issues. We won't make a new Policy upload until after the release, and just after a release is an ideal time to make Policy changes. After the release, when Policy 3.8.1 is released, will be an excellent time to tackle major Policy issues that should affect squeeze development. DocBook Conversion ================== One of the things that Manoj had been working on was converting Debian Policy from DebianDoc-SGML to DocBook and formalizing a new structure that would make it easier to extract bits of information from Policy requirements. This is still a long-term goal. DebianDoc-SGML is no longer widely used, and moving to a more standard format will aid Policy maintenance in the long run. Policy would also benefit greatly from an easier way to extract requirements and recommendations in summary form, a more standardized way of refering to specific requirements in other documents, and a better description of exactly what one should check for to determine whether something complies with Policy. The first step in this process is to develop a new format and style guide. DocBook seems the natural choice for a source language. However, DocBook is a huge language with many, many tags, most of which are probably not appropriate for Policy. We would love to get the input of someone with prior DocBook experience on a style guide. We need a document format and supporting documentation that lists the subset of DocBook that will be used in Policy and exactly when particular tags should be used. If you would be willing to work on this, please mail debian-policy@lists.debian.org. References ========== [1] http://lists.debian.org/debian-policy/2008/12/msg00005.html [2] http://wiki.debian.org/PolicyChangesProcess [3] http://wiki.debian.org/Teams/Policy -- Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Attachment:
pgpzvHbJ8rTuh.pgp
Description: PGP signature