[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Call for Votes (was Re: glibc's getaddrinfo() sort order)



On Sat, Dec 01, 2007 at 01:16:05PM -0800, Steve Langasek wrote:
> On Sat, Nov 17, 2007 at 11:20:22AM +1000, Anthony Towns wrote:
> > Given the discussion we've had it's clear we're not willing to consider
> > this RC, which means stable will remain with its existing behaviour.
> I do think it warrants an update for stable; I only disagree that it's
> relevant to overriding the maintainer.  I would be fine with recommending
> that the SRMs accept an update for etch, but overriding the SRMs decision
> making process should surely be contingent on them having a chance to make
> that decision?

As well as overruling maintainers, we can decide on any matter
of technical policy, or offer advice, without needing to overrule
anyone. "Serious" severity is defined by the maintainer's opinion as
well as the release team's, so afaics we could make it RC by overruling
the maintainer too.

For that matter, our power to overrule a developer only says that we
"may ask a Developer to take a particular technical course of action even
if the Developer does not wish to" -- there's no need for the developer
to have already made a different decision.

Making a resolution like:

    The technical committee finds the behaviour specified in RFC3484 s6
    rule 9 to violate the expectations of people using round-robin DNS
    and Debian machines implementing that rule cause significant load
    imbalances on such servers as a result.

    The technical committee overrules the maintainers of glibc as to the
    validity of Bug#438179 and determines that the proposed solution of
    making the gai.conf's sortv4 option default to yes be implemented.

    The technical committee considers this behaviour to not meet Debian's
    standards for released software, and recommends that the stable
    release managers accept an update to stable to revert this behaviour.

would seem all that's needed to me. That's still dependent on us having
an opinion on whether this is RC though, and that load imbalances in
actual practice actually is the reason we're overruling.

Cheers,
aj

Attachment: signature.asc
Description: Digital signature


Reply to: