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