Re: Funny situation with Licq.

[Daniel Burrows <Daniel_Burrows@brown.edu>]

On Sat, Nov 25, 2000 at 09:42:48AM -0600, Kirk Strauser <kirk@strauser.com> was heard to say:
> The crux of the question is this: how responsible are Debian
> maintainers for fixing upstream code?  If licq.rpm has the same
> problem as licq.deb, is it the .deb's owner's job to fix it?  Or
> is it his (or her) job to make sure that upstream fixes are
> applied and packaged in a timely manner?

  That's why we have a "forwarded upstream" category..
  It's useful to leave such bugs in the BTS so people know that they're known
problems.

> FWIW, I tend to agree with Zed.  While it's possible to make
> every single program trap and handle every single error
> condition thrown at it, that just won't ever happen.

  People make mistakes.  So it's ok to ignore bugreports when a program doesn't
handle error conditions?  Sloppy coding (which I am not innocent of) is a bug.
Especially when it can cause data loss!

  How about this: "While it's possible to make a program deal with any user
unput without crashing, this just won't ever happen."  Based on empirical
observation, this is just as true..hmm, maybe I should close a raft of bugs
against my packages }=)

> Yes, it's good coding practice to check every function for successful
> completion, but how often does that really happen in
> non-critical code?

  Well, I'd hope quite often.

> If this were, say, the support code for a
> programmable cardiac defibrillator, then I'd agree with you
> 100%.  However, it's a little instant-messaging program, and
> nothing horrible will happen if it has to re-generate its config
> file after a crash.

  So it's not a bug?  I don't understand your attitude.  It's still producing
incorrect behavior and causing unnecessary trouble for the user (who has to
reconstruct the lost configuration, or just live with the new, possibly broken
configuration)  Probably you can also lose your whole contact list in bad
situations, assuming that the code to write that out also doesn't check for
errors in write().  This would be a far worse loss, as reconstructing
that can be a real hassle.

  I agree that it's not a showstopper, "drop everything else to deal with this"
bug, but why does this justify ignoring it?

> >  Check http://bugs.debian.org/76815 and laugh! =)
> 
> I was prepared to laugh, Nicholás, but it wasn't that funny.

  I agree about that, at least.

  Luckily, it looks like the maintainer finally understands that writing a
temporary file and using rename() is a good idea, so maybe he'll forward it..

  This is a good reminder, though, that writes *can* fail.  I think I'd better
go audit my code for this issue :)

   Thanks,
  Daniel

-- 
/----------------- Daniel Burrows <Daniel_Burrows@brown.edu> -----------------\
|               I used to be indecisive, but now I'm not sure.                |
\---------------------- A duck! -- http://www.python.org ---------------------/