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]

Reply via email to