Re: [avr-libc-dev] avr-libc 1.2.6 has been released

[Joerg Wunsch]

As Dmitry K. wrote:

> Certainly, I welcome fast release of the bug-fixed version.
> But I am surprised and get vexed by such haste concerning
> a bug #14852 (pow() with negative x).  Unlike others,
> it is the extremely serious mistake which result can be
> destruction of the program.  As there is a patch together
> with a set of tests.
>    It is, I think, impossible to have "active maintainer"
> for every file of Avr-libc.

As stated many times, we don't have an active maintainer for the
entire fplib.  Unless someone really steps forward to take this job
(including taking full responsibility for it, i.e. he needs to do
everything up to the final commit, and he needs to respond as timely
as possible for a hobby job to any problems arising), as I said, I'm
rather willing to rewrite a floating-point library in C, and ship the
current fplib as an add-on ``use at your own risk''.

You're right, I should perhaps have mentioned on top of the NEWS file
that fplib is already in that ``use at your own risk'' state right now
(i.e. I consider it severely broken in many respects).

I simply don't have the time to maintain it, including all test cases
that are required for such maintenance.  That's why I basically ignore
any open fplib bug myself.  Nobody else seems to have the time and
energy to handle them either.

When I offered you the job, you regretted that you don't want to
handle CVS.  While I appreciate all your patches, when *I* am the
person to commit them to CVS, sorry, I first have to make absolutely
sure everything is OK.  Typically, for each of your patches, this
costs all the spare-time of one evening for one or at most two patches
-- not because your patches are of poor quality, but because the issue
is quite complex, and whoever is committing stuff to CVS takes full
responsibility for what he's doing, so I have to completely understand
what you've been doing.  They way fplib is hacke^H^H^H^H^Hwritten
doesn't really make this kind of understanding faster.

I've tried to fix fplib bugs in the past, but quite often found myself
to just open another hole by plugging one of them, due to its design
(which is arguably quite efficient yet drastically increases matenance
overhead).

I'm already wondering whether we should rather have a full set of
dejagnu (or whatever) regression tests before touching *anything* in
fplib again.  But then, I didn't want to invest the time for such a
testsuite before rolling 1.4.0 (because it would delay it
indefinately), let alone yet another bugfix release in the 1.2 line.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)