On Thu, Sep 20, 2007 at 07:01:50PM +0100, Ian Jackson wrote: > There is apparently no counterproposal, so I hereby propose and call > for a vote on the following resolution: > -8<- > 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses > by Debian systems, and we overrule the maintainer. If the > maintainer has not uploaded a suitable change within 1 > week, Ian Jackson is mandated to make an NMU in sid. > 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses > by Debian systems. However, we do not overrule the maintainer > on this point and we do not authorise changing it via an NMU. > 3. We recommend to the IETF that RFC3484 s6 rule 9 should be > abolished, definitely for IPv4, and probably for IPv6 too. > -8<- > For the sake of clarity, we should at least have the libc maintainer's > position on the ballot, so: > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > [2] Choice X: Do not use rule 9, overrule maintainer, etc., as above. > [3] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo > [1] Choice F: Further discussion > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > Rationale for why it should be me that does the NMU: I have already > made this change in Ubuntu in anticipation of Debian's change, and at > the request of James Troup in his capacity as Canonical sysadmin. So > I know how to do it and have a suitable diff lying around. If the > libc maintainer objects then they can make the change first themselves. I agree with Anthony that authorizing NMUs is a bit strange. The TC is charged with deciding the correct technical course of action, and in choosing the maintainer for packages; authorizing NMUs is neither, and thus, I believe, out of order here (and unnecessary besides). Further, if Ian has the suitable diff available I think it ought to be included in this discussion so that the TC has an opportunity to discuss and raise any objections to the particular solution being implemented. (I already know what the diff looks like in this case and don't have any objections myself, but believe it should still be discussed explicitly among all members of the committee.) I also think that if we're going to make a recommendation to the IETF, it behooves us to provide a coherent rationale for that recommendation, and vote on that rationale. I'll elaborate on my take on the rationale in a subsequent follow-up. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature