On Mon, Oct 01, 2007 at 10:44:48AM +0200, Andreas Barth wrote: > * Anthony Towns (aj@azure.humbug.org.au) [071001 03:46]: > > One of the rules for RCness is "in the package maintainer's opinion, > > makes the package unsuitable for release". Not quite the same, but > > not very different is "in the technical committee's opinion, makes the > > package unsuitable for release" -- is that what we think of this issue? > I don't see which advantage we will get from introducing the concept "RC > ness" into this decision. AFAICS, we can perfectly well make a decision > only about the topic in question. 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. In my opinion, if this issue isn't severe enough to warrant a change to stable, it's also not severe enough to warrant overruling the maintainer wrt unstable -- if we're trying to stop Debian machines behaving badly on the Internet, that applies to stable at least as much as unstable. I don't see why stable would be changed for a non-RC issue in this case, nor why this being RC wouldn't warrant stable being changed, so I consider those to be equivalent. OTOH, if we're not that worried about Debian machines behaving badly, but we're trying to influence the future of the Internet, changing the RFC is the way to go, and there's no need to overrule our glibc maintainers or keep more patches from glibc until our concerns have been passed on to the IETF. > If the decision is right, why should we wait for a new document? Because the maintainers, upstream and IETF all currently agree that the other way of approaching things is right. > Especially as the current document isn't a standard either, but the old > behaviour is. I don't believe "the old behaviour" has even reached the level of "proposed standard" in the IETF nomenclature -- certainly I haven't seen any evidence of it up 'til now. If you're claiming it's a de facto standard, well, this is how de facto standards change -- with upstream implemented preferred behaviours, and us releasing them as part of stable. And I realise dismissing RFC3484 as "not a standard" is all the rage, but personally I still give quite a bit of weight to IETF proposed standards. It's possible we've reached the end of the discussion; if other members of the TC don't consider this severe enough to make glibc unsuitable for release and all that entails, then I don't see any way to support overruling the maintainers on the issue -- but that doesn't mean we can't decide to overrule the maintainers anyway: it just means three people need to vote for it, and no one else can vote against it. I have absolutely no qualms putting my name to something saying "RFC3484 is lame", just the bit that says "and it doesn't matter what the glibc maintainers think, this is the way it should be done in Debian". Cheers, aj
Attachment:
signature.asc
Description: Digital signature