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.