On Thu, Dec 06, 2007 at 01:58:47AM -0800, Steve Langasek wrote: > I do think that this bug warrants fixing in stable, I just don't agree that > RCness is the relevant and appropriate standard for whether the TC should > override a maintainer. You seem to be ok with overriding the libconfig > maintainer's choice of source package name, but I haven't seen it suggested > that the libconfig package needs to be renamed in stable? The rationale given for overriding the maintainer is that this is a horrible bug that's breaking Internet servers everywhere, including our own. I haven't seen any evidence of that, but if it's the case, or at least the basis for us to overrule the maintainer, then in order to stop it from happening we should be ensuring it's fixed in stable as well. It seems to me absolutely irresponsible to say an issue's a blight on the Internet, and then not worry about what happens for stable. Well, either that, or dishonest, in that we're not worrying about fixing it in stable because it isn't a major problem, even though we're saying it is. If that's not our rationale, the only other one I've seen is essentially "this is daft behaviour that doesn't do any one any good and shouldn't be in the RFC", which I agree with, but don't think warrants overruling the maintainer's decision that it's not important enough to warrant changing the default behaviour versus upstream. > I'm amenable to including a statement about RCness in the resolution if > that's relevant to getting it passed, I just don't believe it's necessary > for getting the bug fixed in etch. If we're saying "this is a major issue that needs to be fixed throughout Debian, and we trust the maintainers and release team to give that appropriate priority", without explicitly saying "release critical", that's fine, but TBH I don't see any practical difference between saying the above and saying "this is RC", at all. I'm pretty sure I dislike the idea of being eager to dive into issues where we're looking at overruling package maintainers (mixmaster, libconfig and exim, atm eg) and extremely reluctant to even make suggestions about release policy. Particularly when there're plenty of ways of overruling package maintainers (uploading a differently named version of the same software, NMUs, ftpmaster NEW/REJECT handling, peer pressure on -devel, QA monitoring and removal requests, policy guidelines from -policy, RMs setting RC severities, tech-ctte, and GR) and very few of overruling RM decisions (tech-ctte, GR, and conceivably DPL redelegation). > Josip was not the first or only person that I heard say this, but I think > the other comments were made on IRC. I'll try to track down some hard data > on this. From memory, the server in the http.us.debian.org rotation that > was being hit out of proportion was ike.egr.msu.edu, but I don't know yet > that this was confirmed as being a jump in relative traffic as opposed to a > jump in absolute traffic. It would be consistent with RFC3484 behavior on > the part of hosts on 10.x.x.x intranets, though. Well, okay... but shouldn't it still be happening if that's the case? Unless we've somehow lost a significant number of 10.0.0.0/8 hosts that were pointing at ftp/http.us.d.o at that point and now aren't, ike is still the host that they should be all hitting so demonstrating the load imbalance caused by 10.0.0.0 hosts should be trivial if we have any access to ike's logs. Actually, almost every apt host hitting ike via an address above 64.0.0.0 ought to be a NATed 10.0.0.0/0 host (unless it's being proxied from a <64.0.0.0 by a >64.0.0.0 address, or has a real IP <64.0.0.0 but is being NATed to >64.0.0.0 anyway for some reason). If we had logs from ike, that should be enough to give us an estimate on how many 10.0.0.0 hosts we have (x = real hosts for ike, y = 10.0.0.0 hosts; a = <64.0.0.0 address hitting ike, b = >64.0.0.0 addresses hitting ike; b ~= 3/4y; a+b = x+y; y ~= 4b/3; x = a+b-y ~= a+b/4; proportion of 10.0.0.0 hosts to all real addresses ~= y / 4x ~= 4b / (12a+3b)). At some point ftp.us.d.o was just one host, which could also have (obviously) caused one host to get more traffic than the others; but I don't recall when that was, or which host it was though. Cheers, aj
Attachment:
signature.asc
Description: Digital signature