Re: Call for Votes (Re: glibc's getaddrinfo() sort order)
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).
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.
Therefore implicitly, a decision by the TC has to imply that someone
might make an NMU. Questions that need to be asked in connection with
this are: who should make the NMU ? When should they do so
(implicitly, how long will we give the maintainer to do it their
way) ? Does the TC need itself to approve the patch to be applied, as
part of the resolution ?
Now NMU policies might be set by RMs or the DPL or someone, but that
would mean either that the answers to those questions would have to be
fixed, or that each TC resolution would have to be referred to the RMs
for a ruling on when and how an NMU should be done.
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.
So I think you might argue that you wanted to see my patch or that 1
week is too short, or that someone else ought to do the NMU, or
something like that. But I think it's important that every TC
decision to overrule a maintainer explicitly authorise an NMU (rather
than implicitly), and the TC decision itself ought to specify
timescales and circumstances.
I'm surprised to see that AJ is arguing that the TC shouldn't
authorise NMUs. In January 2006 he seemed even to go so far as to say
that a decision to overrule the maintainer ought always to result in
an NMU by the TC chair. I think that (a) we should decide these
things on a case-by-case basis but following some established
precidents (which sadly we don't have yet), and (b) we ought to try to
make things run smoothly.
I don't think we should expect that a TC decision against the libc
maintainer ought to result automatically in a libc NMU upload. That
could be very intrusive and troublesome.
Steve writes:
> Further, if Ian has the suitable diff available I think it ought
> to be included in this discussion so that the TC has an opportunity
> to discuss and raise any objections to the particular solution being
> implemented.
I haven't got it right now in the form of a diff that could be
emailed. If that's helpful then I'm happy to provide it.
But:
> (I already know what the diff looks like in this case
> and don't have any objections myself, but believe it should still be
> discussed explicitly among all members of the committee.)
I think this is a dangerous approach. We don't want the TC discussion
to get bogged down in implementation details.
The package maintainer gets to decide on implementation details,
surely ? (Unless it's those details which are the subject of the
dispute but I'd hope that something trivial wouldn't reach the TC.)
So the right answer is for the maintainer to make the change as
mandated in whatever way they feel is appropriate.
The NMU is for the case where maintainer doesn't want to do the work
necessary to make the change, in the way that they feel best. If the
maintainer doesn't want to make the change then implicitly they're
saying that they find the risk that the NMU is broken or bad somehow
is acceptable, and that they don't feel it's worth their time to avoid
that risk.
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.
Ian.
Reply to: