On Mon, Aug 24, 2015 at 10:25:01PM +0200, Niels Thykier wrote: > > It is really so much difficult to make this in stages? > > For example: > > Stage 1. Make it a policy *recommendation*, with normal severity. > > Stage 2. Make it a policy "should", with important severity. > > Stage 3. Make it a release goal, policy "must", with serious severity. > It would be great if Policy was updated so frequently that was up to > speed with current initiatives in Debian. However, historically, it > often lacks behind on many key parts. Including but not limited to > Multi-Arch (released with Wheezy), which is currently still not > documented in policy (nor in git for the next upload). Multiarch filesystem paths are included in Policy; if they hadn't been, the use of multiarch would have been forbidden because of the FHS. Description of the multiarch control fields is not in Policy, because this was a lower priority; there were other places maintainers could find documentation, and it wasn't necessary to document this in Policy right away for maintainers to know what was required for interoperation, and nobody was looking to make multiarch a Policy requirement. So no one has done the work yet to craft suitable language to describe these fields in Policy - though at DebConf it was clear that people would like to see this happen now. None of that justifies a claim that Policy is slow to update. If someone wants to create a new requirement for packages in the archive, Policy is the right way to accomplish this; and if someone has drafted suitable policy language I see no reason that Policy would be slow to incorporate it. > Also, contrary to popular belief: > Policy does *not* decide if something is an RC bug or not. > That is currently delegated to the Release Team[1], which means that > https://release.debian.org/stretch/rc_policy.txt > is the canonical policy for what is release critical and what is not. It would be bad form for the Release Team to add something to this list that was not already documented in Policy. This document has its origins as a list of *which* Policy requirements the Release Team will enforce as release-critical. Letting that list get out of sync with Policy would be pretty bad for Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature