X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4138" "Tue" "10" "November" "1998" "10:06:02" "-0500" "Michael J. Downes" "mjd@AMS.ORG" nil "87" "Re: What is \"base\" LaTeX" "^Date:" nil nil "11" nil nil nil nil nil] nil) Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1]) by mail.Uni-Mainz.DE (8.8.8/8.8.8) with ESMTP id QAA09244; Tue, 10 Nov 1998 16:06:25 +0100 (MET) Received: from lsv1.listserv.gmd.de (192.88.97.2) by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <5.8715831F@listserv.gmd.de>; Tue, 10 Nov 1998 16:06:24 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 407724 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 10 Nov 1998 16:06:19 +0100 Received: from math.ams.org (math.ams.org [130.44.210.14]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with SMTP id QAA13956 for ; Tue, 10 Nov 1998 16:06:11 +0100 (MET) Received: from sun06.ams.org by math.ams.org via smtpd (for relay.urz.uni-heidelberg.de [129.206.119.201]) with SMTP; 10 Nov 1998 15:06:04 UT Received: from sun06.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) id <0F2700501OM20T@sun06.ams.org> for LATEX-L@URZ.UNI-HEIDELBERG.DE; Tue, 10 Nov 1998 10:06:03 -0500 (EST) MIME-version: 1.0 X-Mailer: Gnus v5.5/Emacs 20.2 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Lines: 87 References: <98110912272255@man.ac.uk> <199811101228.MAA14652@nag.co.uk> <13896.14781.711560.872729@srahtz> Message-ID: <199811101506.QAA13956@relay.urz.uni-heidelberg.de> Reply-To: Mailing list for the LaTeX3 project Comments: Resent-From: mjd@ams.org Comments: Originally-From: Michael John Downes In-Reply-To: Sebastian Rahtz's message of Tue, 10 Nov 1998 13:03:57 +0000 Date: Tue, 10 Nov 1998 10:06:02 -0500 From: "Michael J. Downes" Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: What is "base" LaTeX Status: R X-Status: X-Keywords: X-UID: 2813 David Carlisle writes: > > Any mechanism which introduces extra packages into a central latex > > `minimal distribution' must _not_ generate any extra work at the latex > > support addresses (latex-l and latex-bugs). > > Sebastian Rahtz writes: > have you read Eric Raymond's "Cathedral and Bazaar" paper? your > starting point is the Cathedral system, of a tightly controlled core > run by mages; and, of course, given this, your conclusion is > undeniable. However, Raymond does articulate Another Way (basically, > The Linux Way) which could be applied to LaTeX. I had just read that last week: http://www.redhat.com/redhat/cathedral-bazaar/ and was pondering that very question. Essentially what it would amount to is handing off LaTeX development work to a large world-wide group of "parallel processors" under the following strategy: 1. No pre-screening of the developers. Anyone who wants to work on a piece is free to go ahead and do so. 2. No explicit coordination from the top to divide up the work in an optimal way. Some people might end up working simultaneously on the same problem. Raymond says that in practice this has not been a problem for Linux because there is a natural tendency for people to choose different tasks (all the parallel processors are *different types* and choose their own work); each significant task, in fact, tends to get done by two or three people in slightly different ways: Buzzwords! "Distributed genetic optimization algorithm" 3. The main kind of central coordination involves looking at what contributors have done and selecting pieces to be officially blessed into the standard distribution. For Linux this was done originally entirely by Linus, then later by designated teams for particular areas. I imagine this would often involve picking the best of two or three choices and merging in some nice details from the alternatives that were not selected. 4. Very frequent releases One potential area for trouble that I see is that there is a symbiosis on a given computer between the LaTeX system and the documents that it serves. If one cannot guarantee line break fidelity in existing documents when upgrading to a new LaTeX, people will have to choose between a. Not upgrading b. Upgrading and adding some correction to all the old documents to ensure that their line breaks remain unchanged. c. Upgrading and keeping the old version of LaTeX installed as well (and tying each document to a particular version of LaTeX (and to particular versions of all the packages that it uses (which will not seldom follow a different release schedule than that of the LaTeX kernel) and even of tfm files (recall the scenario a few years ago with interword spacing in the tfm files generated by fontinst: first rather narrow, then changed to wider values in a later release))) I guess this would be equivalent in the Linux world to upgrading and finding that some applications that worked with the old Linux don't work with the new one. In the Linux case, however, most of the applications would presumably be upgraded in due time by their owners, whereas in the case of LaTeX documents *you* are the owner and have to do all the upgrade work yourself. I know that I find myself in this situation rather often: I go back to a document that I wrote two years ago and try to run it through LaTeX again; then I find that one of the pieces that it requires is missing or doesn't work any more. The potential benefits of the bazaar model sound very attractive, enough to warrant a serious look at what it might require. But as a matter of fact I would say that LaTeX development is already proceeding under something very like the bazaar model (the whole contrib area), with only the core being under central control; and even there, improvements have been submitted and accepted from outside the LaTeX team. A more thorough bazaar strategy might involve little more than making the source code repository public. I don't know the details of how that works in the Linux world. Michael Downes