Previously Raul Miller wrote: > First off, I'm not sure it's a good idea for policy to be a rapidly > changing entity.
It's not a good idea at all, but as Manoj pointed out it's now changing rapidly. > Debian produces packages -- policy is a means to that end. No, policy is a means of doing quality-control. > Second, there is the mechanism of the techical committee. The committee > is set up to be able to turn around a decision in a week or less, > once the groundwork has been laid. The current situation [with the > FSSTND->FHS directory migration] is taking longer than that, but it's > hardly a normal situation. Why is it hardly a normal situation? I fail to see this. The way I see it is that policy is made via consensus on debian-policy. I can see that you might want the ctte to bless a policy-change before a new version of debian-policy is uplaoded, but it should not set policy. In fact the constitution states at various point that creating policy should not be done by the ctte. The ctte comes into action when there is a conflict, either via section 6.1.2 or 6.1.3 in the constitution. In this case there is such a conflict, and it is taking the ctte *weeks* to come up with a decision. At this stage I'm tempted to invoke section 5.1.3 of the constition and make a decision based upon the strategies that were discussed here earlier and rethink how the technical committee should work, since it looks like it is not working the way it is supposed to. Wichert. -- ============================================================================== This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/
pgpxEu4Rk21zt.pgp
Description: PGP signature
