Re: Building with pdump litters /usr/local/bin

APA> Don't forget the potentially most prominent platform SJT> Which is why I want testers using the pdumper by default. SJT> There probably are very few, and those obscure, general bugs SJT> left in the pdumper, but I want to be as sure as possible. SJT> Making the Windows platform rock-solid in this respect is SJT> worth the slight risk to Unix platforms. mb> You don't need testers. I've got enough platforms here at mb> ETL. The Release Manager is not talking about platforms. He's talking about programs. You are only one tester with a particular idiosyncratic pattern of usage, no matter how many platforms you build XEmacs on. _You_ didn't find the buffer-local variables problem, the command-line switches don't work problem, or the PostgreSQL environment variables problem, did you? And given your instinctive distaste for the whole PostgreSQL interface, you could build on 1000 platforms and not find it. Your work in platform coverage is very valuable. It is only one dimension of what will make this an acceptable release, however. We also need many different usage patterns tested for these subsystems. Including people who don't use them at all but are impacted by "collateral damage." Also interactions bewteen usage patterns and platforms. Should be extremely few, but you never know. Therefore you test. mb> I am aware of various portability (!) problems with pdump and mb> have a patch in progress for fixing them. Good. Fix those bugs. mb> pdump is not as portable as it looks. For example, it is not mb> 64-bit clean. *shrug* I'm not arguing that 64-bit platforms are unimportant. If you have us ready for 64-bit while the dominant platforms for XEmacs are still 90% 32-bit, that's a win, a win win, a win-win-win win. And it's worth giving you BiaCS status to fix them now while you're interested in them, even though it has a clear negative impact on expected overall quality of _my_ release. But this is a technical detail, well-modularized. Not like the "no-mule XEmacs barfs on Mule files" problem. Not really a "portability" problem, rather a "not fully portable yet" problem. mb> Besides, I was referring to the code we ship, not the current mb> state of CVS. What we ship should be whatever's best for the mb> users. On the principle I agree. But whether pdump on or off is "best for the users" depends on a number of things. I personally don't have a problem with undocumented cruft in my .../bin directories---but that's because Debian is full of such. If that really bothers sysadmins, then it's a problem and we should favor defaulting to off. But the Release Manager wants to hear more discussion about it. If it's a small minority of clean-freaks who care, and the functionality is more robust, then I (personally) say document it in PROBLEMS and the FAQ and people who hate cruft can use the unexec dumpers. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."