Anthony Towns writes ("Re: getaddrinfo() behaviour"): > In my opinion, if this isn't an RC issue, there's no urgency to having > glibc changed prior to the standards changing, and as such, this isn't > the "last resort" so the tech ctte shouldn't be deciding the issue, let > alone overruling the maintainer.
You are assuming that the documented standard[1] will change, and that it will change in a timely manner. As I have said before, it is not the job of the TC (or of Debian!) to slavishly follow standards. [1] I'll go along for the sake of argument with the proposition that the documented standard is rule 9 for IPv4, even though that propositionis actually false. Standards like those in the IETF and elsewhere often allege that they document existing practice, and when we follow some incorrect documentation we are in fact undermining the quality of the standards-setting process. It is wrong of Debian to follow incorrect standards. We should fix brokenness straight away, not wait for a glacial standards body to react. Also, you suggest that it would be wrong of the TC to overrule a maintainer for a non-RC reason. I think that is absurd. The TC should overrule a maintainer whenever it is sufficiently clear that the maintainer is wrong, and the supermajority requirement specifically serves to ensure that the TC will only overrule in that case. Limiting the TC's power to overrule a technical decision to only cases where the TC believes that the wrong behaviour makes the package unsuitable for release would eviscerate the only mechanism we have for dealing with errors by maintainers. Ian. (Added CC to glibc) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]