Hi Stefano, Since you don't seem impressed by my arguments for keeping the support for configure.in, I will just stop wasting time and drop this discussion. I can't help myself though, and find myself repeating my arguments one last time...
- I don't want to convert the GGI project from CVS, I don't have the time nor the energy to verify the conversion and fixup the inevitable hickups, touch up the documentation and web site, set up commit hooks and all the other stuff that goes with it. (That doesn't mean that I don't want to see it done, I just don't fancy doing it). - I don't want to make it even harder to search the CVS history with a silly rename of a bunch of files that contain much information about the history of the project. If you still want to remove support for configure.in, as you seem keen to do, then do it. But if so, thanks in advance for the pebble in my shoe. Very comfy. That's it, over and out on this subject. [re SGI support] >> What do you gain by the zap? >> > Not shipping broken code, and not having to debug/fix it for the > benefit of a vanishingly-small user base. I agree, the zap is ok. But the rationale in NEWS comes out all wrong in its current incomplete state. Cheers, Peter
