Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!ucbcad!ucbvax!hplabs!hplabsc!daemon
From: daemon@hplabsc.UUCP
Newsgroups: comp.mail.elm
Subject: Future maintenance of ELM
Message-ID: <2183@hplabsc.HP.COM>
Date: Tue, 7-Jul-87 13:55:29 EDT
Article-I.D.: hplabsc.2183
Posted: Tue Jul  7 13:55:29 1987
Date-Received: Fri, 10-Jul-87 01:59:08 EDT
Sender: daemon@hplabsc.HP.COM
Reply-To: epiwrl!epimass!jbuck@seismo.CSS.GOV (Joe Buck)
Organization: Entropic Processing, Inc., Cupertino, CA
Lines: 46
Approved: taylor@hplabs (with 'postmail')


>In article <2061@hplabsc.HP.COM> taylor@hpldat (Dave Taylor) writes:
>Perhaps we should also discuss a new full-source posting to the net
>or something.  The problem with that is that there is a LOT of code
>and it seems rude to keep posting it.

The solution is Larry Wall's method of handling rn.  The ELM world
should adopt it.

1) Post a clean version of ELM (version 1.6?).  The current state
   is too confused, with the way the 1.5b patches were handled,
   plus all the patches people posted.  The release should contain
   a "patchlevel" or "patchlevel.h" file.  This version should NOT
   be posted until it runs successfully on both a 4.2 or 4.3bsd
   system AND a pure System V system (if necessary, let's get some
   beta test volunteers -- a Sun would be a good test site because
   it bombs on dereferencing null pointers).  We don't want to flood
   the net with a megabyte of stuff that doesn't compile on a lot of
   systems.

   The README file should emphasize the importance of keeping the
   unaltered source (as modified by official patches).

2) Maintain ELM by posting official, numbered patches.  As users
   discover bugs they may patch the source on their own, but they
   ALWAYS keep around the official code so patches can be applied.
   The patches should be context diffs, not ed scripts or normal
   diffs; "patch" can successfully apply context diffs in most cases
   even if lines have been added or deleted from the file; they are
   more robust.

3) We need a single person to be in charge of releasing the official
   patches.  Bug reports and suggested patches will be sent to that
   person, or just posted to this list (emphasizing that they are
   UNOFFICIAL patches), and s/he will post official patches.  Ideally,
   that person should be Dave Taylor (hi Dave!), because ELM is his
   creation and I think he should decide, especially in the case of
   "enhancements", whether ELM should really work in a certain way.
   If he does not have the time, I volunteer (provided that step 1
   is done correctly and the initial posting is not a major disaster).

Comments?
-- 
- Joe Buck    jbuck@epimass.EPI.COM
	      {seismo,ucbvax,sun,decwrl,}!epimass.epi.com!jbuck
	      Old arpa mailers: jbuck%epimass.EPI.COM@seismo.css.gov