<div dir="ltr">On Tue, Apr 9, 2013 at 5:28 PM, Philip TAYLOR <span dir="ltr"><<a href="mailto:P.Taylor@rhul.ac.uk" target="_blank">P.Taylor@rhul.ac.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
<br>
Zdenek Wagner wrote:<br>
<br>
> If I knew about a bug in my package, I would not put it to CTAN. The<br>
> infrastructure maintainers would not burn a DVD if they knew about a<br>
> bug. I remember one year when one CSTUG member found a bug in binaries<br>
> just a few days before planned DVD production and the developers<br>
> recompiled all binaries before producing the DVD.<br>
<br>
</div>This is exactly my point :  are we giving the field testers<br>
long enough to identify that there are bugs a forthcoming<br>
TL release?<br></blockquote><div><br></div><div>I'd agree that failure to identify "significant" (e.g. serious impact on many users) </div><div>bugs during prerelease testing has been a problem in the past.  I worry that TL</div>

<div>adds new capabilities every year so that only a small fraction of the potential combinations and permutations can be tested.</div><div><br></div><div>I rely on a) my own testing and b) making sure I have access to at least 2 TL</div>

<div>versions.  With linux this typically means current CTAN TL + vendor TL.   After IT</div><div>installed a new McAfee module that thinks most TeX programs are suspicious</div><div>("Anti-spyware Maximum Protection:Prevent execution of scripts from the Temp folder<span class="" style="white-space:pre">  </span>Action blocked : Read", I've given up trying to use Windows for actual work.</div>
<div><br></div><div>In my own testing I try to find time to run boilerplate documents from publishers</div><div>we use, package documentation, and a small number of existing documents.   I</div>
<div>try to format documents using all 3 main engines (pdftex, xetex, and luatex) on </div><div>all the platforms we use (linux, OS X, and in the past, IRIX and Solaris) but </div><div>don't spend much time checking details of formatting.  Generally the test documents</div>

<div>are small.   These tests are useful to me because they often reveal minor changes </div><div>that we need to make in our templates.  In recent years, most of the "bugs" I have</div><div>found were caused by differences between the build system and our local machines.</div>

<div><br></div><div>I don't test two types of documents that are more likely to encounter problems:</div><div><br></div><div>1.  the user-written article/report template that has been accumulating \usepackage </div>
<div>lines year after year (and storing the .sty files with their documents!).</div><div><br></div><div>2.  documents that rely on newly introduced features.  People who have such documents should be testing them early and often. </div>
<div><br></div><div>The tricky part is that new features often break older documents, sometimes with </div>
<div>good reason and sometimes inadvertently. </div><div><br></div><div style>Most really successful open source projects depend on a minor diety to severely trim excess baggage.   For TeX Live, even if the major diety were to trim stuff from the distribution, old .sty files will keep coming back to cause problems until LaTeX is changed to reject them.  This makes TeX Live an ecosystem.   In the spirit of "it isn't wilderness unless you are on the menu", in the TL ecosystem, your documents are on the menu.</div>
<div style><br></div></div>-- <br>George N. White III <<a href="mailto:aa056@chebucto.ns.ca" target="_blank">aa056@chebucto.ns.ca</a>><br>
Head of St. Margarets Bay, Nova Scotia
</div></div>