XEROX LISPUSERS' RULES 2 4 1 LISPUSERS' RULES 1 4 This document describes the rules and procedures for Interlisp "LispUsers" packages. This document is mainly for LispUsers package writers, but users should also understand the rules. DEVELOPING LISPUSERS PACKAGES A LispUsers package is a useful program made available to the general Interlisp programming community. Neither the author nor the custodian of the LispUsers directory imputes any warranty of suitability or responsibility for errors. LispUsers packages should try to be easily distinguished from released library packages. In particular, this means that packages may not have the same name as a Library package and should be visibly different. LispUsers packages derived from released software should be announced to the public only after communicating with the organization responsible for that released software. Testing is important. If you make significant changes to a LispUsers package, enlist your friends as alpha testers. Avoid having to rerelease a package within hours of its announcement because of fatal bugs. A LispUsers package is not shoddy software; it is software made available outside the regular release channels. Try not to flood your user community with a constant flow of new versions (or messages) so your messages can be appreciated rather than discarded without reading. If your package is undergoing continual changes, adopt a release strategy of regularly spaced, well tested releases. Your users will thank you. LISPUSERS PACKAGE OWNERSHIP A package stored on the directory remains the "property" of the submitter. Others may not make changes, except for their own private use, without negotiating with the owner (who may already be making similar or incompatible changes). In general, changing a package on the directory implies a willing transfer of ownership. As the owner of a package, you are not required to fix bugs, but if not, you must be willing to transfer ownership (permanently) to someone who volunteers to fix them. Ownership may pass back and forth among several people as long as they agree. A LispUsers package may become so useful that it becomes part of a standard Interlisp-D release and is thereafter supported. Ownership then passes to the product organization. ANNOUNCING LISPUSERS PACKAGES You should send announcements of your package to the LispUsers^.x mailing list. In your announcement, you should include the package name, where it is stored, what other packages are stored with it, and some general description of the package. It is also advisable to send announcements of major changes to your packages, or of transferral of ownership. STORING FILES ON LISPUSERS Store your packages on {ERIS}releasename>, where the releasename is the name of the release in which it is run. This directory has complete read, write and delete access for everyone. This means that once you put a LispUsers package here, everyone can use it. If you wish to make changes to an existing package, you should ask the author about it, or create a new package based on the old one. If you remove one of your packages from LispUsers, please announce its removal, to save users from possible confusion. As with released software, it is important to store not just the resulting product, but all the files needed to build and maintain a lisp users package: 1. the runnable .DCOM 2. documentation describing it, following the set formatting rules (see below) 3. files used to build it 4. data files Packages submitted once are released once. If you want to release a package that is good for more than one release, you have to make multiple copies, and, whenever a new release gets shipped, copied again. Users are responsible for assuring that their packages get moved to the new ReleaseName> directory if they want them rereleased. If no notice is given about old packages, they are assumed to be obsolete. This procedure provides for some positive mechanism for verifying that packages are still "alive". Once packages are released, they are moved to {ERIS}ReleaseName>LispUsers>, which is a protected directory. Normal users only have read access to this directory, so that the released packages remain static. Any new versions of released packages should be stored onto the original LispUsers directory. DOCUMENTATION Documentation, essential to any package being used effectively, should be put on the directory, too. No packages will be released without documentation. Documentation can be as simple as a paragraph describing what the package does and how to use it, or it can be as extensive as a dozen-page user manual. All packages should have a file with a .TEDIT extension, formatted according to the rules outlined in the file ReleaseName>DocumentationTemplate.TEdit. This is a rather long explanation for those who are not familiar with TEdit formatting. For an easier version, look for the file ReleaseName>EasyTemplate.TEdit. Both of these files are released on the floppies as of the Koto release, as well as stored on the release directory, and all users, external users included, should follow these rules. If the documentation is large and formatting time consuming, you can also produce a interpress file (with the .ip extension), along with submitting a .TEdit file. (Be sure to update the interpress if you update the documentation!) Documentation should include the full electronic mail address of the submitter. COMPATIBILITY WITH LISPUSERS Any file on the directory should be compilable in a "vanilla" environment. The file itself should load in any auxiliary packages under a suitable (DECLARE: EVAL@COMPILE -- ) when necessary. A directory might look like: Koto>BIGFOOT BIGFOOT.DCOM BIGFOOT.TEDIT BIGFOOT-DATA Thanks for your cooperation. (LIST ((PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC) STARTINGPAGE# 1) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (174 36 288 36) NIL) (HEADING NIL (HEADINGTYPE RUNNINGHEAD) (84 744 528 36) NIL) (TEXT NIL NIL (84 96 456 600) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC) STARTINGPAGE# NIL) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (174 36 288 36) NIL) (HEADING NIL (HEADINGTYPE RUNNINGHEAD) (84 744 528 36) NIL) (TEXT NIL NIL (84 96 456 600) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC) STARTINGPAGE# NIL) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (174 36 288 36) NIL) (HEADING NIL (HEADINGTYPE RUNNINGHEAD) (84 744 528 36) NIL) (TEXT NIL NIL (84 96 456 600) NIL)))))(Č(ŠŠ8(ŠŠ8DČČPAGEHEADINGRUNNINGHEAD(MODERN MODERN MODERN MODERNMODERN MODERNLOGO?1(DEFAULTFONT 1 (GACHA 10) (GACHA 8) (TERMINAL 8)) HRULE.GETFNMODERN HRULE.GETFNMODERN HRULE.GETFNMODERN HRULE.GETFNMODERNHRULE.GETFNMODERNşęC5]÷±b(Ú™R%Ř:îąŞĘF%[zş