On Fri, Nov 30, 2007 at 06:53:57PM +0000, Ian Jackson wrote:
> Anthony Towns writes ("Re: Call for Votes (getaddrinfo)"):
> > 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 you think that RCness (or desire to fix in stable) is relevant,
> surely the question is whether _you_ think this bug is severe enough
> to be RC ?
No, not really. Like I said in September [0], my rating of possible ways
to address this issue in regards to overruling the maintainer is:
[1] This bug isn't important enough to overrule the maintainer
[2] This bug needs to be fixed in all suites (ie, it's RC), and
should be fixed in unstable immediately by defaulting sortv4
in gai.conf to no
[3] Further discussion
[4] Just overrule the maintainer, don't worry about whether it's RC
[5] Overrule the maintainer, in spite of this not being RC
I would've thought others would've voted:
[1] This bug needs to be fixed in all suites ...
[2] This bug isn't important enough to overrule the maintainer
[3] Further discussion
with the result being "fix it in all suites" beats "don't worry about
it", and has a 7:0 supermajority. But you and Andi both seem to prefer
"don't worry about whether it's RC".
I don't see any reason to like the current behaviour, so parallel to that,
I'd also say:
[1] We should work out what a desirable prefix sorting behaviour
is, that works the same way for IPv4 and IPv6, and propose it
to supercede RFC3484.
[2] We should pass on concrete reports of harm rule9 causes for IPv4
round-robin servers to the IETF with encouragement for them to
review the sorting rules.
[3] We should do nothing but hope the IETF and upstream work something
better out themselves and not follow the standard until that
happens.
[4] Further discussion
I haven't seen any concrete reports we could pass on, or any indication
we're likely to come up with a better mechanism, though, which leaves us
as doing nothing by default.
> Would you vote in favour of a resolution which insisted on pushing the
> change to stable, would you vote in favour ? I think not. So it's a
> red herring.
As I said in September, and above, I'm not convinced this is an RC issue,
but at least it's a consistent resolution, so I'd be happy to vote it
above FD.
I could be convinced it's RC, but I've seen precious little *actual*
impact -- certainly people are surprised by the change in behaviour,
and it does change traffic characteristics, but ... that seems to be it,
so far. Where's the actual damage and problems?
> I think that it will be easier to convince people to push it into
> stable after we've demonstrated that it works well in testing.
Well, yes; but saying something's an RC issue doesn't determine what
will be done to correct it, just that something has to be done, both
for testing and unstable, _and_ for stable.
We haven't discussed any specific way of changing the sorting behaviour
for stable, and I don't see any need to. Establishing whether or not
the issue's RC and warrants a stable update is something we should be
doing afaics though.
> If you think it's a release-critical bug and that it ought to be
> changed in stable, surely you should vote in favour of my resolution
> as a step towards that goal ?
The rationale in your resolution for the importance of this issue (afaics)
is that (11) it's incompatible with round-robin, (12) it overloads servers
that expect round-robin behaviour when clients use rule9. If those are
our reasons, that makes this an RC issue -- it's equally important this
be fixed for our existing stable release as well as testing/unstable.
But the resolution doesn't say that, and when I brought this up in
September, you indicated it wasn't necessarily RC:
] I think that it should be changed in etch. [...]
]
] I can see that the stable release managers might have another view.
] We haven't really heard from them properly. My current feeling
] therefore is that we should overrule the libc maintainer to
] essentially propose this ourselves as an update for stable, which we
] would recommend but not insist that the stable RM should accept.
-- http://lists.debian.org/debian-ctte/2007/09/msg00072.html
and Andi likewise wanted to keep the RC decision in the RM's domain:
] Frankly speaking, I don't think we should already jugde about [RCness].
] 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).
]
] ...
]
] I don't see how RCness is related to the question.
-- http://lists.debian.org/debian-ctte/2007/09/msg00077.html
As it stands I think the resolution is inconsistent -- it claims to be
trying to stop lots of clients using rule9 on round-robin servers and
thus causing them to crash under the unbalanced load, but then ignores
all the clients running stable that might be doing the same thing (and
seem more likely to be causing a problem if there is one, to me).
And again, I haven't seen any evidence that rule9 is actually causing
round-robin servers to crash; ftp.us.d.o or otherwise -- the closest
I've seen is Josip's comments, and he apparently doesn't actually have
access to those machines to see what's going on...
The original request was more about providing an easy way for a
programmer to avoid the sorting while using getaddrinfo(), which would
then require weighing up "which is more sensible, follow a proposed
standard that's being used upstream, or making things work in a more
traditional/common-sense way?" rather than concers regarding impact on
round-robin servers. I'd be hard pressed to see a decision made on that
basis as as requiring a change in stable, but we seem to have changed
the basis of the issue from sane-APIs to the real-world impact of Debian
boxes, though, and that definitely should affect what we do with stable.
Cheers,
aj
[0] http://lists.debian.org/debian-ctte/2007/09/msg00071.html
Attachment:
signature.asc
Description: Digital signature