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. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev