[SGVLUG] Developers fast to fix open-source bugs

[David Lawyer]

On Wed, Apr 05, 2006 at 07:10:27PM -0700, matti wrote:
> 
> fyi - thought this was interesting
> 
> best
> matti
> 
> ---
> 
> Developers fast to fix open-source bugs
> http://news.com.com/Developers+fast+to+fix+open-source+bugs/2100-1002_3-6057669.html

My experience has been the opposite.  Some Debian packages like
linuxdoc-tools, or hwclock (part of package util-linux), are (or were)
unmaintained so bug report accumulate, including ones that include
code to fix the bug.  But years go by and it never gets fixed because
there's no maintainer.

For hwclock, I had filed so many bug reports, I was asked if I wanted
to maintain it.  One reason hwclock doesn't get fixed is that it's
still usable the way it is.  The binary code works fine, but the
problem is in the start-up script and documentation created by the
Debian distribution.  The Debian documentation has been "fixed"
to tell you not to use the feature that doesn't work right (automatic
compensation for hw clock drift).  Unfortunately, the Debian
documentation conflicts with the man-page documentation.  The failure
to work right could be fixed by a simple change of the init script for
it.

In fact I've fixed my script (mostly by commenting out lines) so that
automatic compensation for drift works fine.  Since my hw clock runs
fast (battery powered when the PC is off) by 1.518286 seconds per day,
the hw clock is automatically retarded (by the hwclock program) this
amount every day (or the appropriate amount based on the clock time
when it does this, which is just after booting).  When I set the time
to the correct value every few months, it corrects the 1.518286
figure, which is likely only accurate to about 3 significant figures
anyway.  This way my, time stays pretty accurate in spite of a fast
clock in my PC hardware.

But for bugs in widely used software like the kernel, bugs likely get
fixed faster since there are people maintaining it.  A bug which I
reported which caused the kernel to boot about 30 sec. slower on an
old PC got fixed in a few weeks.  New PCs didn't have this bug since
it was a race condition.  The referenced report claiming fast bug
fixing seemed to be for widely used and well maintained programs.
But that's not always the case for little-used programs, or sometimes
for little used features of more widely used programs.

			David Lawyer