[tex-live] TL2004: Technical problems and testing

[Karl Berry]

Hi Martin and all,

    for DANTE, NTG & GUST not producing this CD/DVD in the current state 

Obviously no one is contemplating shipping what is in perforce right now.

   Proposed solution: Add the old locations of the files to
   texmf.cnf and if needed change kpathsea so that the old
   locations are also searched.

 I don't disagree, but I guess it's Thomas who needs to be convinced.

       We also discussed more robust ways of communicating (proposed)
       changes. No conclusions were drawn yet.

What is wrong with email to tex-live at tug.org?  Everyone relevant is on
that list.  It is discussions/decisions *off* the list which cause
problems, in my experience.

Of course I know that many people on tex-live don't care about all the
ins and outs.  If you think a smaller list would serve us better, that's
fine.  Although much can be accomplished at physical meetings,
ultimately email is the only thing that can bring us together; physical
meetings, wherever in the world they are located, will necessarily
exclude many key people.  (And I do *not* mean me.)

      Proposed solution: Keep support for pdftex.cfg, but declare it
      as deprecated and support only the mapfile entries. All other
      entries are ignore (with a warning).

Sure.  But what do you (Martin) think, as you're the one who has to
implement it :)?  I assume you're ok with it or it wouldn't be getting
proposed :).

    - eTeX will be the only engine. This should cause no problems.

Well, I agree with this as stated, but I believe we currently use tex
for tex.  I personally don't feel strongly whether "tex" invokes the
original tex, or etex in compatibility mode.

    - pdfeTeX as the only engine. This could lead to several
      compatiblity problems, most with packages that are unable to
      handle pdfTeX in dvi mode.
      Proposed solution: Do not switch to pdfeTeX as the only engine
      now, but maybe in 2005.

There is another solution, as we've discussed here at length: use
pdfetex with a .ini file which undefines the pdftex extensions to
generate the non-pdf tex's.

    TL2003 had several bugs which where caused by not testing the
    product on systems of average (non TeX/os expert) users. The
    proposed solution is to initiate a controlled beta-test program.

The more testing the better, no doubt.  The problem is finding testers,
good or otherwise.

    - Testers will be required to fill in an application form.

Sorry to say so, but I think this is simply unrealistic.  Even with no
overhead of an application form, I have received only about five
responses to my repeated requests on ctt, texhax, and tug mailings for
testers.  (I had planned to email those people when there was something
to test.)  In other words, right now we are not in a position to pick
and choose.

If you can get 20 people to respond to your queries, then great, by all
means, choose the ones who will give the best reports.  It would be a
nice luxury to have.

I strongly advise we all send out queries on the membership lists to get
a sense of how many people are interested, before spending time devising
a form, which could be a huge time sink with no actual practical use.

    Time schedule:

Well, if we really cut the production cd's around 9/1, that would be ok
(not great), but I do not like the idea of *assuming* we won't ship
until 9/1.  

    1. 20040601: Feature freeze, beta releases ready. Beta testing

Ok by me, but it really depends on Olaf, Thomas, Fabrice, Gerben, and
the others who have to write the code (in the next 3 1/2 weeks,
according to this) so there is something stable to test, and Sebastian,
who puts it all together.  These "decisions" cannot be made in a vacuum.
We're all volunteers.

    2. 20040801: Beta testing ends, master is prepared for
                 production.
    3. 20040901: TL2004 ships, when all problems are resolved.

Sure, testing should take however long it takes to get a usable product.
Three months is not an unreasonable guess.  My concern is that we not
use the schedule as an excuse for doing nothing until the final
deadline.  Last year, Staszek was essentially the only tester until well
after the original agreed-on deadline was passed, causing the thing to
be 3 months late and still buggy, as we all know to our sorrow.

This year, we were doing reasonably well with the early schedule that I
circulated (and we all more or less agreed to, if you remember) earlier
until the last few weeks, when it seems little progress has been made.
I hope that will reverse.

    - Iso-images and archives of binaries and pool files for the
      various plattforms are produced regularly and made available,

By Sebastian, as has been done in the past?  Or are you proposing that
someone else is going to be responsible?  And if so, who?  

     via CTAN if possible, or other public ftp servers otherwise.

As is well known, uk-ctan does not currently have the disk space to
store any TL test images, and I doubt all the mirrors would want many
gigabytes of test images either.  So I don't think it can be distributed
via the regular CTAN mechanisms.

This is basically why the test image production happens on tug.org now.
If the test images can get distributed from another machine or two,
that's fine, whatever.  I don't think performance has been an issue.

   Distribution:
   - live-DVD
   - installable CD

Yes to those two.

   - live-CD (runnable from CD), 700mb

We have discussed this at length too, and I was under the impression
that we had all agreed to drop this in favor of a copy of the miktex cd,
basically to save the endless hassle of choosing packages.  If you are
dropping that idea, then ok, no big deal, but again, who is going to
produce it?  Are you assuming Sebastian will?


I look forward to a successful cooperative effort once again, and a
reliable TeX Live 2004 release :).

Regards,
karl