On Thu, Nov 29, 2007 at 07:51:37PM +0000, Ian Jackson wrote:
> -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> [ ] Choice X: Do not use rule 9, overrule maintainer, etc., as above.
> [ ] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo
> [1] Choice M: Leave the choice up to the maintainers.
> [2] Choice F: Further discussion
> -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
The don't delete anything between these lines seems pointless since we're
not using a program to tally votes...
Again, if we don't think this bug is severe enough to need to be fixed
in stable (and thus qualifies as RC), I don't think we should be overruling
the maintainer.
If Josip's correct in saying that this is screwing over the Debian
apt round-robin hosts, it seems like we should be saying this is RC, but
nobody seemed willing to do that when I brought it up earlier.
> 4. Prior to the publication and implementation of RFC3484, and prior
> to the introduction of getaddrinfo, most hosts would use an
> implementation of gethostbyname to find IPv4 addresses to use for
> a peer, given its hostname. gethostbyname has almost universally
> returned the addresses in the order supplied by whatever DNS
> nameserver it was using.
getaddrinfo() also almost universally behaved that way until very
recently.
> IPv6 transition
> 7. The primary use of getaddrinfo is to replace gethostbyname when an
> application is converted to support IPv6.
I would say the primary use of getaddrinfo is to resolve a domain name
in a useful way. I don't think replacing gethostbyname is relevant --
if it behaves differently to gethostbyname that's a win if it's more
useful and a loss if it's less useful; it's not always a loss merely
because it's different.
> 9. There are no known applications which specifically desire the
> rule 9 behaviour; we know of no case where an application uses
> getaddrinfo specifically to get rule 9.
RFC3484 specifically allows rule 9 to be overriden if the implementation
has a better process, so it's not reasonable for an application to rely
on rule 9, afaics.
> 10. There is therefore no rational reason for the difference
> between the behaviour of gethostbyname and getaddrinfo, other than
> perhaps implementation convenience.
Consistency between IPv4 and IPv6 behaviours seems a perfectly rational
desire, even if it doesn't warrant the cost of changing the application
behaviour.
> 11. Rule 9 is incompatible with the DNS Round Robin.
It's perfectly compatible, it just overrides it.
> 12. When Debian's apt changed its behaviour to follow rule 9,
> it broke ftp.us.debian.org because the load suddenly became very
> unbalanced. Thus this incompatibility causes actual operational
> problems.
I've seen no evidence that that actually happened. There's some
hearsay from Josip ("I'm told that thisbug also broke round-robin DNS
functionality for ftp.us.debian.org/http.us.debian.org"), but that's it.
> Standards
> 18. The purpose of standards is interoperability. Where following a
> standard makes us less interoperable we should not follow the
> standard. Debian is entitled to deviate from standards, including
> published documents, if we consider it appropriate to do so.
This doesn't affect interoperability either way, though.
It changes the impact of Debian systems on services provided by
round-robin hosts (ie, to possibly impact some servers more than
others, depending on the distribution of clients, rather than
doing equal balancing), and it results in changed expectations of
users/developers/admins as to how host resolution on round-robin addresses
will work.
> 23. It appears that RFC3484 is also unhelpful for IPv6. However,
> since there is no existing de-facto standard for IPv6, this
> conclusion is arguable.
RFC3484 is relied upon by other IPv6 drafts/standards in order to choose
the correct class of address for a service (a roaming address versus
a static one, a site-local address versus a global one, etc). Some of
those can be dealt with by earlier rules (particularly site-local versus
global), but that leaves many RFCs that do rely on the rule for IPv6.
> Backporting to current stable
> 26. In my opinion this change should be backported to current
> stable. However, this decision does not need to be taken now. We
I think this should be the maintainers' call.
The call I think we should be making is whether this is an issue that
needs to be corrected in stable, whether by the patch we've seen, or by
some other means. If that fix doesn't happen immediately, but waits for
further testing in unstable and lenny, that's fine -- it'll be waiting
for the next point release in any case.
Again, if we don't think this is sufficiently serious to need to be
fixed in stable, afaics that means we're ignoring the impact of Debian
machines on round-robin services as an important consideration --
including ftp/http.us.d.o and security.d.o.
> 28. One committee member has insisted on the presence of `leave the
> choice up to the maintainer' on the ballot (option M). My
> understanding of the meaning of this wording is that if that
> option wins we refuse to make a decision on the matter and also
> refuse to deal with it any more. Ie, this option is equivalent to
> Further Discussion except that the committee will not discuss or
> vote any more but instead considers the matter closed.
> 29. I do not consider it appropriate for the committee to decline to
> issue a ruling. Once a matter has reached us it is for us to make
> a decision and we should not abdicate that responsibility.
We should *always* decline to make a decision unless we have clear
evidence that it's *necessary* for us to step in. That is to say, it
must be *important* that the issue be resolved, and that the maintainer
cannot already be resolving it.
I can't see any way in which this issue can be important enough to
be resolved without it also being important enough to resolve for our
current stable release too, which afaics would make it by definition
release critical. I don't understand why everyone seems to be passing
on declaring it RC or important enough to need fixing in stable.
> If the
> committee disagrees with the maintainer, but not sufficiently
> overwhelmingly so as to be able to overrule the maintainer,
If the issue isn't particularly important or the maintainer is already
handling it satisfactorily, the ctte shouldn't be spending its time
agreeing or disagreeing with the maintainer. I'd say 412976 would be an
example of that.
> In this particular case the committee does seem
> to have a sufficient majority to overrule, if we can only get the
> mechanics of voting working properly.
Overruling the maintainer should be an absolute last resort, not something
we do anytime we see something that 75% of us happen to disagree with.
> 30. It has also been suggested that we should not overrule the
> maintainer unless we consider the bug release-critical. This is
> an abdication of the responsibility of the committee.
It's the responsibility of the technical committee to determine which bugs
are important enough to warrant our attention to disputes about them. Not
determining whether this bug is release-critical, which is to say warrants
an update to stable if it applies to packages in stable, is abidicating our
responsibility to evaluate the importance of this issue afaics.
Maybe you're in effect saying:
- the use of rule9 for a function resolving IPv4 addresses is
RC in glibc if many applications in Debian use that function for
IPv4 addresses
- there are/will be many applications using getaddrinfo() for IPv4
addresses in lenny, so this is RC for lenny and must be resolved
- there aren't many applications using getaddrinfo() for IPv4
addresses in etch, so this does not need to be resolved
(though it'd be nice if it were)
I've been assuming there are already sufficient getaddrinfo apps in etch
that this is relevant for etch if it's relevant for lenny, but maybe
people disagree with that?
I could endorse that, though I was under the impression that apt in etch
used getaddrinfo for IPv4 resolution (which would seem sufficient Debian
apps in etch to me to make the issue equally relevant to etch).
> In
> particular, whether or not to overrule the maintainer should
> depend primarily on how _clear_ it is that the maintainer is
> wrong, rather than on how _serious_ the consequences are.
I strongly disagree with this. Maintainers get things wrong very
frequently; it's their job to fix these things, not the technical
committee's. If the issue isn't both important to Debian *and* being
mishandled/ignored by the maintainer, it's not in our purview.
Establishing a policy or practice where the only bar to us overruling a
maintainer is that someone reassign a bug to us and 75% of those of us
who can be bothered voting disagree with the maintainer is a terrible
idea, IMO.
As a consequence, I'll continue voting any attempts to overrule the
maintainer that don't (IMO) clearly and consistently establish why the
issue is important to Debian below further discussion.
And again, the only way I can see this issue being important to Debian
is the overall effect of many Debian machines accessing round-robin
services and failing to do so in a balanced way. But afaics, if we are
using that as our basis, it applies equally to stable and unstable,
and warrants being treated as a release critical issue. If we're not
willing to take that issue that seriously, I don't see any aspects of
this problem that are important enough to warrant tech-ctte resolution.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature