Re: getaddrinfo() behaviour
Anthony Towns wrote: On Mon, Oct 01, 2007 at 04:30:17PM +0100, Ian Jackson wrote: Ian Jackson writes (Re: getaddrinfo() behaviour): 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. I should have said, for dealing with errors by maintainers which persist after persuasion has been tried. Updating the proposed standard has not been tried. If it had, and failed, and did so without addressing the concerns we've had with the current rfc, it'd be appropriate for the tech ctte to rule -- we would have exhausted all other means of obtaining a consensus, and it would be the last resort. No! There is one or two updates for the proposed standard. IIRC one is in the last phase, before to be published. [But anyway they are about IPv6, and not rules 9] To check: http://www.ietf.org/ put in the search 3484 and you see a lot of discussions about updates So it seems (IMHO) that RFC3484 is not mature to be (and become) a Internet standard. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
* Anthony Towns: Updating the proposed standard has not been tried. Just to give you an idea of the time scale involved: moving RFC 3484 to HISTORIC (which is the most likely result, at least for the Rule 9 part) will take at least a year. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
Anthony Towns writes (Re: getaddrinfo() behaviour): The only reason suitability for release is relevant is in overriding the directive that we'll not make a technical decision until efforts to resolve it via consensus have been tried and failed. We haven't made efforts to get a consensus with the IETF working group and change the standard that all this stems from, so making a decision before that's happened requires further justification in my view. That refers to efforts within Debian, not to efforts in standards bodies. Standards bodies generally make and implement decisions on a timescale that makes Technical Committee decisions look frenetic and rushed. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
On Tue, Oct 02, 2007 at 08:37:42AM +, Florian Weimer wrote: * Anthony Towns: Updating the proposed standard has not been tried. Just to give you an idea of the time scale involved: moving RFC 3484 to HISTORIC (which is the most likely result, at least for the Rule 9 part) will take at least a year. So let's try early ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpBIrflgPd1C.pgp Description: PGP signature
Re: getaddrinfo() behaviour
On Tue, Oct 02, 2007 at 10:37:42AM +0200, Florian Weimer wrote: * Anthony Towns: Updating the proposed standard has not been tried. Just to give you an idea of the time scale involved: moving RFC 3484 to HISTORIC (which is the most likely result, at least for the Rule 9 part) will take at least a year. Likewise, updating stable for a non-RC issue takes a similar amount of time... Cheers, aj signature.asc Description: Digital signature
Re: getaddrinfo() behaviour
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]
Re: getaddrinfo() behaviour
Ian Jackson writes (Re: getaddrinfo() behaviour): 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. I should have said, for dealing with errors by maintainers which persist after persuasion has been tried. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
On Mon, Oct 01, 2007 at 04:30:17PM +0100, Ian Jackson wrote: Ian Jackson writes (Re: getaddrinfo() behaviour): 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. I should have said, for dealing with errors by maintainers which persist after persuasion has been tried. Updating the proposed standard has not been tried. If it had, and failed, and did so without addressing the concerns we've had with the current rfc, it'd be appropriate for the tech ctte to rule -- we would have exhausted all other means of obtaining a consensus, and it would be the last resort. If there hadn't been a proposed standard in the first place documenting the existing behaviour, I doubt we'd have a problem in the first place, and there certainly wouldn't be an issue with us overruling the maintainer if there somehow was. The only reason suitability for release is relevant is in overriding the directive that we'll not make a technical decision until efforts to resolve it via consensus have been tried and failed. We haven't made efforts to get a consensus with the IETF working group and change the standard that all this stems from, so making a decision before that's happened requires further justification in my view. I can't say I'd noticed much effort from the ctte to persuade the glibc maintainers of anything, to be honest. Cheers, aj signature.asc Description: Digital signature
