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

Re: ifupdown's changed hook handling breaks other packages.

On Sat, 16 Jun 2012 19:33:27 +0200
Andrew Shadura <bugzilla@tut.by> wrote:

> > If it is a bug in NetworkManager, then please show me where.
> auto eth0
> #NetworkManager#iface eth0 ...
> is not a valid syntax.
> So when we have interfaces 'defined' like this, initscripts' hook
> thinks we've got all 0 interfaces up so it can start. Of course, this
> needs to be fixed so it won't even try to do so. But the source of the
> problem is that NetworkManager was abusing a bug in ifupdown's parser.

It would have been a lot easier for everyone if this had been mentioned
in the original bug report - why was this not done?

> I think that reassigning a bug to network-manager in a first place was
> a clear enough message that something needs to be changed, so
> reassigning it back multiple times isn't a good way of communication
> either.

This has been escalated to debian-devel precisely because that mere
reassignment was *not* and was never going to be a sufficiently clear
message for the network-manager maintainers to be able to triage the
bug. ifupdown has lots of bugs, NM has lots of bugs - there's no excuse
for not providing information which would help fix the bugs.

If the ifupdown maintainers had some idea of why the original bug was
down to a package abusing a bug in the parser then just putting those 6
words into the message alongside the reassignment would have saved a
lot of aggravation and started the process of getting this bug fixed.
It doesn't have to be proven, just a hint that it could be related to a
bug fix in the parser would have been a start.

All this reassignment ping-pong - which is just as idiotic as severity
ping-pong - could have been avoided if the original bug report had had
a follow up message about this parser bug being fixed and your
suspicions that network-manager and possibly other tools were abusing

If you think a bug fix in your package has (correctly) prevented other
tools from abusing the bug then, as the maintainer of the package
providing the parser bug fix, it *is* your responsibility to mention
this fact in bug reports which could be related to this change and to
do so before the bug report is re-assigned.

"This sounds like your package is abusing a bug in our parser which was
fixed for bug #" - is that so much work that you didn't have time to
type it in the comment of the original re-assignment?

That knowledge must be shared with the other team - as early as
possible and certainly without requiring an escalation to -devel.

Co-operation is the core of free software - if some maintainers can't be
bothered to help their fellow maintainers by adding a sentence to a bug
report, those maintainers are doing it wrong.


Neil Williams

Attachment: pgpGJit1PhjxM.pgp
Description: PGP signature

Reply to: