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.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
