Re: getaddrinfo() behaviour
* Ian Jackson (ian@davenant.greenend.org.uk) [070928 17:48]:
> Anthony Towns writes ("getaddrinfo() behaviour"):
> > Conversely, if we don't consider this an RC issue, changing it for etch
> > doesn't seem appropriate, and at that point I don't see why we'd change
> > it for sid either (at least absent an update via the IETF standards track
> > process). I'd be interested to see explanations of why this should be
> > considered RC.
>
> I think that it should be changed in etch. If we change it in etch it
> will make our ftp admins' lives a lot easier, if nothing else, because
> they'll go back to being able to publish DNS round robin.
Frankly speaking, I don't think we should already jugde about that.
IMHO, the tech ctte should make minimal decisions (as appropriate of
course). The large decision at our hands is "how should the long-term
strategy look like" - after that decision is done, I think we (as tech
ctte) could let take the maintainers plus stable release managers
decide how to continue for etch (and if someone is unhappy enough to
call the tech ctte again, we could decide on that).
> Since I did the backport for Ubuntu I'm probably the right person to
> prepare the update for etch (not that it's very hard).
That's something I didn't like to have as part of the decisions as well,
but I didn't mind enough - we should first say "yes, *that* is the right
decision". I always consider the usual rules for RC bug fixes apply as
well to "implement decisions of the tech ctte", but I don't think we
should especially assign someone to the solution.
(Of course, in case the implementation goes wrong, we might decide "oh,
that is exactly the patch we would like to see implemented", but I don't
see a reasons for that in this case.)
> > If so, conclusions that could potentially be drawn:
> >
> > (a) Using prefix matching to select IPv4 addresses isn't useful
> > (b) Using prefix matching to select IPv4 addresses is harmful
> > (c) Using prefix matching to select IPv4 addresses is harmful enough to
> > be an RC issue for Debian
> ...
>
> > If so, declaring this to be an RC issue justifies both an update to
> > etch and (if necessary, which I don't expect) an NMU for sid/lenny,
> > which seems all that's needed.
>
> I don't see why RCness is relevant for updating sid.
I don't see how RCness is related to the question.
The maintainers did a certain decision. Now somebody didn't like it and
asked the tech ctte to overrule the maintainers. Now the tech ctte could
(a) decide to back up the maintainers, (b) decide to not like the
decision, but don't overrule the maintainers, (c) overrule the
maintainers.
I didn't read yet that the release managers made a decision that this
issue is RC or not, and I also cannot remember that someone asked the
tech ctte to overrule the release managers. So RCness is a question not
even asked here.
> Surely the TC should ensure that its decisions are implemented even if
> we consider the issue non-RC ?
Sure
> I think we should avoid getting too bogged down with IPv6. We can
> safely leave that to the IETF to reconsider since we're evidently not
> going to overrule the libc maintainer on that point. Hence my wording
> that we think rule 6 shouldn't apply to IPv6 and we recommend the IETF
> "probably" abolish it. Ie, they should think about it with the more
> information and expertise available to them.
Agreed. I think we should try to get a decision on what affects us and
where at least anyone inside the tech ctte is willing to override, i.e.
how to continue with IPv4. We seem to agree we don't overrule on ipv6,
and we also seem to agree in case we overrule on ipv4 that reconsidering
ipv6 is sound - so we shouldn't split hairs on the best wording there,
but try to get this issue off.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: