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

[Steve Langasek <vorlon@debian.org>]

On Sun, Sep 23, 2007 at 04:02:25PM +0100, Ian Jackson wrote:
> Anthony Towns writes ("Re: Call for Votes (Re: glibc's getaddrinfo() sort order)"):
> > I don't think the tech ctte should be authorising themselves to do NMUs
> > under any circumstances.

> Steve Langasek writes ("Re: Call for Votes (Re: glibc's getaddrinfo() sort order)"):
> > I agree with Anthony that authorizing NMUs is a bit strange.  The TC is
> > charged with deciding the correct technical course of action, and in
> > choosing the maintainer for packages; authorizing NMUs is neither, and thus,
> > I believe, out of order here (and unnecessary besides).

> Well, the question is what happens if the maintainer doesn't want to
> do the actual work to make the change mandated by the TC.  We can't
> mandate that the maintainer do so - see constitution 2.1(1).

If the maintainer doesn't do the actual work, we have normal NMU rules that
let non-maintainers fix bugs.  I think those are sufficient, and if they
aren't I don't think we can bootstrap legitimacy here by including it in a
TC ruling.

> We've had one situation in the past where the maintainer failed to
> implement a decision of the TC and eventually the TC's decision was
> withdrawn because the world had moved on.  I don't think we should
> allow that to happen again.

That's fine; I'm not saying you shouldn't NMU glibc if the maintainers are
unwilling to implement the change, I'm only saying it shouldn't be written
into a resolution because authorizing NMUs isn't one of the TC's powers.

> Surely it is better for the TC to decide the answers to these
> questions on a case-by-case basis ?  Sometimes the change will require
> writing a significant amount of code, and we'll need to negotiate
> carefully with all the interested parties.  But in other cases (like
> this one) it's a very simple change at the level of the code and we
> don't even care if the `work' (such as it is) of preparing a patch is
> done more than once.

Well, it's with AJ's earlier suggestion in mind that I suggested a concrete
patch be included in this discussion.  If we're asked to make a technical
decision, why leave any ambiguity about the implementation?

> I'm very happy to leave that decision up to the maintainer.  The
> remaining question then is just how long we should give them.  I think
> for this change 1 week is fine but if you want a longer period then do
> say.

No, I think a week is plenty of lead time for an NMU.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/