[tex-k] Twiki is broken; sorry . . . let's use tex-k list if that's okay.

[Tomas G. Rokicki]

It appears that the twiki I set up is broken.  Tom E. added some very
useful and pertinent comments (a couple of paragraphs), and I saw them
with my own two eyes, but now they've gone.  I thought Twiki was safe
because it uses RCS underneath, but in the underlying RCS files there
remains no trace of Tom E.'s comments at all.  So I have to declare that
Twiki, or perhaps my installation of Twiki, is broken, and let's just
discuss this on this list, unless that's inappropriate.

I'm very sorry and very red-faced and quite disappointed.

Tom E.'s comments, as near as I can remember, clarified the relationships
among the releases, and also mentioned a key dichotomy for driver
development:

* Standalone development, using a version of kpathsea that is also
  standalone, vs.

* Shared source tree with TeX and friends.

His words are so much better than mine that I'm hoping he will rewrite
them.

In the meantime, the current Agenda file looks like:

Purpose of meeting:  determine home of dvips and discuss release of beta.

Tom R.'s view:  home should be TeXLive tree as maintained by Seba and available on sun.dante.de.

Question:  will this suffice for Tom E.?  Should we negotiate to have it be the teTeX tree maintained by Tom E. instead?  Especially since the main teTeX is Tom E.'s?

As for Macintosh, etc., I've given up trying to support a non-dvipsk version of dvips.  Sorry.

Next issue:  beta releases and timing.  We need to be aware of distribution releases so we know when to check in major changes and how to integrate with the distribution testing schedules.

Next issue:  I'm starting this Twiki web that will allow people to participate in some of these discussions.  We'll see how well it works out.



*Tom E's view:* I agree that timing is a problem if the sources are changed online. Checking out from the TeXLive server is not a technical problem for me and I doubt that the integration into teTeX  is difficult (it used to be very easy for me in the past).

teTeX's sources are not available online. There is another reason why I do not think that dvips's primary source should be in teTeX: in the past, there have always been periods where I could not work on teTeX or where some big change (e.g from web2c-6.x to web2c-7.x) caused a long delay for the next release.

But, even if we consider TeXLive the primary place where dvips is
maintained, there should be unboundled releases of dvips from time to time. Many TeX users are not members of any user group and do not want to by anything (i.e. some book with a TeXLive CDROM) and cannot download an ISO-Image. But it is not only "users", but derivate versions that suffer if there are no unboundled releases. Take for example MikTeX which includes dvips. I am not sure if its author is happy to download TeXLive just to get the latest dvips.

So, my opinion is that we should find someone who takes the latest sources from time to time and makes an unboundled release.

Summary: for *me* (personally) it is ok to maintain dvips in the TeXLive tree, but I think that someone should create snapshots for users who just want to update dvips and for people who create a derivate product.

*Tom R:*  By unbundled release, do you mean independent of web2c, or TeXLive?  A major problem in the past for me is that the build and install environment is a major portion of the product; I'm not sure how to unbundle the source in a way that gives you something that still builds and installs.  But I agree about the timing of releases, testing, and changing.  Having dvips only available as part of a full TeX installation really makes my life much much easier.

Feel free to look at the ToDo list.


*Olaf:*  When it comes to "base" releases, note that I can maintain web2c and kpathsea, but simply do not have the time to take care of all of texk.  Thus the texk bits that I use tend to be direct imports from other sources, like teTeX or TeXLive.  The web2c/kpathsea master sources themselves are not available on a public repository.  (I use cvs.)

To avoid the duplication of a lot of effort, I also believe it is best for web2c/kpathsea to be a base of other distributions like teTeX and TeXLive.  The texk distribution should, if it is retained at all, just be a cut-down version of one of these (right now it is effectively a cut-down version of teTeX.)

One thing that's been on my todo list for some time now is to make the kpathsea library easier to install/upgrade separately from the other programs, and then to package it separately.  For dvipsk (and xdvik) that would mean the program can be packaged by taking the dvips plus the kpathsea sources and you have something to distribute.  Note that there are some provisions for this even today -- the current dvipsk makefiles may have retained the ability to create a dvipsk tarball by running 'make dist' in the dvipsk subdirectory.  (For web2c, that is how the web2c* tarballs are made.)

*Tom R.:*  Excellent!  So if web2c/kpathsea is a stripped down teTeX, then the real question is:  teTeX or TeXLive as a base?  Advantage of TeXLive is the perforce tree is on the net.  Advantage of teTeX is that it is the basis for TeXLive (and thus, any changes made to teTeX in the TeXLive tree need to be copied by hand into the teTeX tree).  I believe this is the status quo, and though it's not great, so long as Thomas Esser is willing to do that work, I have no trouble.

Please note that perforce (what TeXLive uses) has excellent branching and integration capabilities, so it is possible to fork off development branches and stable branches and still get patches applied across the branches.  Perforce does this much better than cvs, for instance.  So careful use of perforce may solve the timing issue to a large extent (as long as we all communicate release schedules appropriately).

*Olaf:*  One thing to note is that the way we develop things also varies.  I do most work on a laptop which doesn't have a 24x7 connection, and for my peace of mind it does have a local CVS repository of the web2c sources.  In fact, I've also hand-modified files in the repository to ensure that the *.web files have the "Knuthian" timestamps, rather than the timestamps of the date I checked them in.  So one situation I'm faced with is that I have one repository (mine, CVS) which contains changes that should go into another repository (TeXLive/perforce) or three (xdvi/sourceforge CVS, Omega/CVS server in .au). So far I've had the luxury of simply being able to push a tarball and have other people do the merging...

Mostly this works because the sources are reasonably modular, used in comparatively clean ways, and updated in mostly-compatible ways.  You can basically rip out an old web2c/kpathsea, put in the new, and need only a few fixups to have everything work again.

Where this will break down is when the library interfaces of kpathsea are changed in incompatible ways -- and some of the changes I have in mind imply this.  At the very least you would not want such a change to occur just a few days before the deadline for (say) TeXLive 7.

*Tom R.:* Good point; perforce is nearly useless offline.

*Olaf:*  Just in case there is a misperception: web2c/kpathsea is not a stripped-down teTeX.  Texk is, because there are quite a lot of little packes to keep up with.  Also note that Sebastian forked a web2c release 7.3.3.1 (or something), with most of these changes folded into 7.3.4 (the rest (of those I wish to adopt) should be in 7.3.5) -- but some in quite different ways.  Flow of changes has probably been in all directions by now...