dsill@RELAY.NSWC.NAVY.MIL (06/23/89)
Okay, I've given some thought to the organization of the elisp
archives. I'll describe what I have in mind, then you can
flame/praise/comment upon it.
Everything I dumped under elisp-archive initially will be put in a
subdirectory called "own-risk", indicating that there are no
guarantees that it:
-will run
-is documented
-won't damage anything on your system
In other words, use this code at your own risk.
Other subdirectories will be set up such as those suggested recently
by Chris Siebenmann:
modes - various major modes
interfaces - interfaces to other systems (eg dbx.el, mh-e.el)
perhaps with subdirectories for X, news, etc.
packages - bundles of functions that don't make a mode
functions - individual useful functions
misc - things that don't fit elsewhere
Any others?
I would place code under these directories only after I'm satisfied
that it is sufficiently safe and that its purpose, installation, and
use is adequately documented. I would also require the author to
include the GNU General Public License.
I'd also change the "contact" field of the Lisp Code Directory
datafile to indicate the location of the code if it's in the archive.
This would allow an elisp-archive-retrieve command to be hacked up, as
well as indicating if an item is in the archive.
I think this approach would maximize the availability of the code
at a minimum of effort to the contributors, maintainers, and users.
One unresolved issue is how to name the archive files. In most cases,
I can simply use the author's name. Sometimes, however, the author
hasn't provided a name, or the name isn't unique, or the code consists
of modifications to a distributed package such as rmail.
Comments, please?
-Dave Sill
dsill@relay.nswc.navy.mil
elisp archive coordinatorkjones@talos.UUCP (Kyle Jones) (06/23/89)
Dave Sill writes: > Everything I dumped under elisp-archive initially will be put in a > subdirectory called "own-risk", indicating that there are no > guarantees that it: > -will run > -is documented > -won't damage anything on your system > In other words, use this code at your own risk. All the code in the archive should be considered "use at your own risk". I don't think you should even attempt to verify that a package won't damamge anything on anyone's system. Emacs itself comes with no warranty, so you can't gaurantee programs running under it. > Other subdirectories will be set up such as those suggested recently > by Chris Siebenmann: > modes - various major modes > interfaces - interfaces to other systems (eg dbx.el, mh-e.el) > perhaps with subdirectories for X, news, etc. > packages - bundles of functions that don't make a mode > functions - individual useful functions > misc - things that don't fit elsewhere > Any others? terms - like the lisp/term directory in the Emacs distribution. I'd hope new term files would be migrated rapidly into Emacs distribution but the archive would be a good interim place for them.
wjc@ho5cad.ATT.COM (Bill Carpenter) (06/24/89)
In article <8906221943.AA10716@ucbvax.Berkeley.EDU> dsill@RELAY.NSWC.NAVY.MIL writes: > One unresolved issue is how to name the archive files. In most cases, > I can simply use the author's name. Sometimes, however, the author > hasn't provided a name, or the name isn't unique, or the code consists > of modifications to a distributed package such as rmail. I reiterate my suggestion that authors provide 13-or-fewer-character names (including ".el") for these files. Although many users are on long filename systems (including osu-cis), many others are in the land of 14's. It may seem a pain to make the sacrifice, but it seems better than having to have half the population randomly renaming many of the files they use from the archive. -- Bill Carpenter att!ho5cad!wjc or attmail!bill
rbr4@uhura.cc.rochester.edu (Roland Roberts) (06/27/89)
In article <8906221943.AA10716@ucbvax.Berkeley.EDU> dsill@RELAY.NSWC.NAVY.MIL writes: >Other subdirectories will be set up such as those suggested recently >by Chris Siebenmann: [elided] >Any others? termcap - I started working on a termcap for our Human Design Series terminals but never completed it (I wimped out and used its vt220 emulation mode). -- Roland Roberts BITNET: roberts@uornsrl Nuclear Structure Research Lab INTERNET: rbr4@uhura.cc.rochester.edu 271 East River Road UUCP: rochester!ur-cc!uhura!rbr4 Rochester, NY 14267 AT&T: (716) 275-8962