vin> I ALWAYS want to know about failures. Me, too. I use function test-file () { \ src/xemacs -no-autoloads -l tests/automated/test-harness.el \ -eval "(test-emacs-test-file \"tests/automated/$1-tests.el\")" ; } If you're not worried about Mule stuff or have a good multilingual terminal, an -nw speeds it up by an order of magnitude. vin> Testing vin> /opt/src/xemacs-21.4-2003-09-25/tests/automated/regexp-tests.el... vin> regexp-tests.el: 248 of 252 tests successful (98%). vin> I'd much rather wade through tons of bogus passes in order to vin> find out what tests actually failed. Where and when? When you build locally, or in every build report? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

|--==> "APA" == Adrian Aichner <adrian(a)xemacs.org&gt; writes: Vin> I happen to agree that we don't really care about passes, but Vin> I ALWAYS want to know about failures. Your latest patch Vin> doesn't produce the failure information needed: APA> This exactly was my motivation to make the problems on all APA> platforms visible via build-report feedback of make check*. I'm not sure, but I think that there may have been some misunderstanding all round here. Let me try to clarify my view which seems to have been such a catalyst to all this. First off, I am _NOT_ referring to what goes into a build-report at this stage. All I'm talking about is the output from 'make check'. Now, I'm all for verbosity, the more the merrier, I say. Verbosity is good, verbosity gives people warm fuzzies, we should always err on the side of verbosity. Which is why, Adrian, I initially supported your patch to test-harness.el. That's the good news, now the bad (not so good)... With your patch, Adrian, after I have done a 'make check' I can't immediately see how much of the test suite passed. - If I'm inside XEmacs, I have to search through or scan the entire compilation buffer. Not impossible, but a PITA, nonetheless. - If I'm outside of XEmacs _and_ I've redirected the make output to a file, I have to search through the output file. Still a PITA. - If I'm outside of XEmacs, but forgot to redirect the make output to a file, I'm screwed. I don't have a hope of finding out how much of the test suite passed or failed. My suggestion for a "fix" to this situation is to put a summary at the _end_ of 'make check', in the form: foo-tests: n of m tests successful (xxx%) bar-tests: n of m tests successful (xxx%) So once 'make check' completes I can see immediately how many tests have passed. If I see anything other than "100%" I can scroll back through the compilation buffer to find the failure(s). Please understand that I am _NOT_ suggesting that we do away with the verbose output from 'make check', IMO 'make check' should be as verbose as possible. All I'm suggesting is that a summary be added to the end. As an added enhancement, I would also like to see, after the summary, something like: ====================================================== Total: nnnnn of mmmmm tests successful (xxx%) Please report ANY failures via 'M-x report-xemacs-bug' ====================================================== Have I explained my views and ideas in a way that is clear and you understand? Adrian? Steve? -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - The only _______ you'll ever need. | | Fill in the blank, yes, it's THAT good! | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: SJT> You had better not do another release before the Microsoft %e issue is SJT> resolved, though, or I will FUCKING SCREAM! I _am_ supposed to know what you're talking about, right? [1] SJT> But it should be fixed in print.c, and that's not my job. When we start paying you for your time and expertise you can say that, although we still won't pay any attention to it. :-P Footnotes: [1] For those who have a problem with subtlety, I have no idea what the "Microsoft %e issue" is. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - The only _______ you'll ever need. | | Fill in the blank, yes, it's THAT good! | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "GC" == Glynn Clements <glynn.clements(a)virgin.net&gt; writes: GC> Steve Youngs wrote: GC> See the thread entitled: GC> [Success/exposed test failures] XEmacs 21.4.14 "Reasonable Discussion" i586-pc-win32 Ah OK. No prizes for guessing the two reasons why I didn't read that thread.:-) -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - The only _______ you'll ever need. | | Fill in the blank, yes, it's THAT good! | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: SJT> Neither of which is acceptable for the beta release manager. Blow me! -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - The only _______ you'll ever need. | | Fill in the blank, yes, it's THAT good! | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "JJ" == Jerry James <james(a)xemacs.org&gt; writes: JJ> Steve Youngs <youngs(a)xemacs.org&gt; wrote: SJT> Neither of which is acceptable for the beta release manager. JJ> I have to admit that I'm not up on Australian slang. We got it from the yanks. JJ> Where I come from, though (the exotic foreign country of JJ> nearly-Southern California), this is a mortal insult. Precisely why I used it. JJ> I think Stephen is right, so it is disturbing to see you reply JJ> in what appears to be an insulting way, rather than offering a JJ> reasonable response. So here's a "reasonable response" for you: I am an incredibly busy person who has very little time for anything. Because of that I make decisions very quickly. That usually means ignoring things that I don't consider important. As the 21.5 release manager the 21.4 tree has low (note I didn't say "no") importance, but I do keep an eye on it. Windoze has _never_ given me any reason to apply even the slightest amount of importance to it. I can't ever see that situation changing. Couple those facts with the fact that I honestly believe with every ounce of my being that the worst mistake the XEmacs project has ever made was to support windoze and you should soon understand why I ignored a thread about windoze on 21.4. JJ> I hope I mistook your intent. I hope you didn't. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - The only _______ you'll ever need. | | Fill in the blank, yes, it's THAT good! | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|