hack@bellboy.UUCP (Greg Hackney) (06/02/88)
Sydney Weinstein (syd!dsinc) has volunteered to coordinate
future releases of Elm bug fixes. (He sent email saying he
was willing to start with the pure 2.0 gamma.)
Are there any other volunteers? If so, please speak up, and
we as a newsgroup can take a vote as to who. This is not
intended to be a moderator position, but a coordinator
to accept bug reports, see to it that the fixes run on
various machines thru volunteer testers, and to issue
new releases as deemed necessary.
Today is the 1st, how about letting this message propagate
for a while, and take a vote in about 3 weeks. I'll volunteer
to take votes later and post the results.
Comments, suggestions?
--
Greg Hackney
Southwestern Bell Telephone Co.
root@tness1.UUCP
{ihnp4 | bellcore}!tness1!rootedc@ALTOS.COM (Eric Christensen) (06/06/88)
Back when Dave first had to give up coordinating Elm bug fixes, I volunteered to coordinate future releases. At the same time, someone else also volunteered to coordinate. Since I was really too busy at the time to do a good job of it, I let this other person do it (notice that I'm not mentioning names). Well, obviously it didn't work out, for whatever reason. Hence, here I am again volunteering to coordinate Elm. I would prefer to start with the 2.0 gamma (is that o.k. Dave?), but if there's enough demand, I'll go back and do a posting of 1.7. I can provide annonymous uucp as well, although I don't want to be flooded with requests for 2.0 gamma sources yet. There seems to be some debate over the legitimacy (is that a real word?) of the 2.0 gamma sources. Until Dave either turns over the "real" sources to the duly elected coordinator, or gives his blessing to the current 2.0 gamma sources, I don't feel that they should be widely distributed. I will maintain source trees under SCCS and RCS which can be pulled from via uucp. This will help ensure that several of us don't undo each others fixes and enhancements. I have used this system for several "real" projects where we have engineers spread all over the world. It worked real nice, as long as it's properly maintained. (Note: I have never done the dual SCCS/RCS source tree before. Do we need it? Or is RCS only sufficent? I don't mind the extra work, but I don't want to waste time creating and maintaining 2 source trees if everybody is using RCS.) I personally can test under Xenix 3, Xenix V, Unix V/386 (i.e. 5.3.1), SVR2, and SVR3.1. I also have access to a VAX running 4.2, but I don't want to commit to testing there until I talk to it's master about it. I can be reached at (408)433-3614 virtually any time of the day or night (yes, I AM a workaholic). If I'm not there, my PhoneMail is. :-) And of course, by Email. -- +-------------------------+---------------------------------------------------+ | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | | Altos Computer Systems +---------------------------------------------------+ | 399 West Trimble Road | Definitions: Bug - An Undocumented Feature | | San Jose, Ca. 95131 | Feature - A Documented Bug | +-------------------------+---------------------------------------------------+ | These views aren't Altos' - They're mine, all mine, and you can't have them | +-----------------------------------------------------------------------------+
edc@ALTOS.COM (Eric Christensen) (06/08/88)
In article <343@vector.UUCP> chip@vector.UUCP (Chip Rosenthal) writes: >No disrespect to Dave's wishes, but if 2.0 is better than 1.7, let's start >there. (Unless 2.0 gamma was a leak which wasn't supposed to happen.) Well, I've exchanged a couple of email messages with Dave about what the 2.0 gamma is, and where it came from. His answer is this: Dave Taylor: "In reference to your question about the 2.0 gamma sources, well, let's put it this way; just before I left HP Labs [more on that in a sec] I made available for HP internal use a version labelled 2.0 beta and another 2.0 gamma. If somehow a similarly labelled version of the source has made it out of HP without my knowledge and explicit action, then I am of clear conscience in saying "do what you want with this renegade ;-) version", right? Besides, at this relatively late date in the game the myserious new source has been distributed sufficiently widely that I couldn't rightly stop it anyway, so ..." So be it. However, there are several problems which are fixed in this 2.0 "renegade" version. It is Dave's recommendation that we take start with the 2.0 gamma which leaked and work from there. In my opinion, it would be a waste of time to work the 1.7 sources at this point. >After all this and a clean 2.0 is posted, it might be a good idea to add >a note to the posting that all bug reports should be sent to the coordinator >rather than being posted. My guess is that there enough folks to pitch >in and minimize the job for the coordinator. Agreed! I volenteered to establish an RCS and/or SCCS tree to work from. I'll coordinate it, and check sources in and out of the tree. That way we have a controlled set of sources with full documantation about what has changed. In addition, I'll also grant uucp access to the tree for a (hopefully fairly small) group of people who are doing work on elm. That way we can minimize the "your patch undid my patch" gripes that always seem to happen. >Greg Hackney (hack@bellboy.UUCP) posted a message soliciting names for >coordinator and other volunteers. Can we agree that we should take him >up on this offer, and let him put together a list of names? Heck, I'd >even be willing to let him collect votes if he's interested. Absolutely! If we are to get elm back under control, we need 1 coordinator, and 1 sub-coordinator who can take over in the event that the coordinator gets run over by a truck. The sub-coordinator should have full access to the master source tree so he/she can collect said sources in the event of some disaster. In addition, we need a set of "official" beta sites. By official, I mean people who are actually going to test and maybe fix beta releases before they are posted to comp.sources.unix. I don't mean elm "end users" who just want the latest and greatest sources, but aren't/won't/can't contribute anything to the effort. If beta releases aren't controlled, we'll just get more and more confused. That would probably mean the end of Elm, which is last thing any of us want to see happen. Comments? Suggestion? Gripes? Flames? I'll take 'em all!!!! -- +-------------------------+---------------------------------------------------+ | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | | Altos Computer Systems +---------------------------------------------------+ | 399 West Trimble Road | Definitions: Bug - An Undocumented Feature | | San Jose, Ca. 95131 | Feature - A Documented Bug | +-------------------------+---------------------------------------------------+ | These views aren't Altos' - They're mine, all mine, and you can't have them | +-----------------------------------------------------------------------------+
donegan@stanton.TCC.COM (Steven P. Donegan) (06/12/88)
Since there appears to be a well qualified No. Cal. Tester/Coordinator for Elm, perhaps I should simply offer to be a So. Cal. distribution point. I would be happy to keep up to date sources available via annonymous uucp. Any comments? -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM
donegan@stanton.TCC.COM (Steven P. Donegan) (06/12/88)
In article <1090@bellboy.UUCP>, hack@bellboy.UUCP (Greg Hackney) writes: > In article <343@vector.UUCP> chip@vector.UUCP (Chip Rosenthal) writes: > > >Greg Hackney (hack@bellboy.UUCP) posted a message soliciting names for > >coordinator and other volunteers. Can we agree that we should take him > >up on this offer, and let him put together a list of names? Heck, I'd > >even be willing to let him collect votes if he's interested. > > I'm doin' it. Just waiting until next week to post a ballot. I > think I will go ahead and call for votes starting the 12th > since a lot of people will be going to USENIX the next week. > There are 4 volunteers to date. I'll post some general background > info on them. > > >2.0, test it out, clean it up, de-lint it, roff it, shar it > > Sounds like smokin' dope. > > -- > Greg Well, I think perhaps smoking source code tightly rolled in old 96 column cards might get some of the general hacker types off, but on to more serious issues: Let's have a vote, Greg - please tally same. I've volunteered to provide annonymous uucp access, coordination or assistance in debugging/verifying 286 XENIX (SCO 2.2.1) Elm. I currently have Elm 1.7 running under XENIX and would be more than happy to share it for those who don't want to wait for 2.0 I am working on the 2.0 release (?) that I uucp'd from killer a while back. as soon as I can get past the @#!$% segmentation/stack/heap problems under XENIX compiler I will be more than happy to make it available too. Let's get together on this issue, hack the hell out of the code (1.7/2.0), and make the code available to anyone who wants it. I think that this could result in an evolution for Elm and perhaps serve as an example to the net of a cooperative project that works. Thanks Greg for your attempts to get people together on this - I think it's working! -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM
darrylo@hpsrli.HP.COM (Darryl Okahata) (06/20/88)
In comp.mail.elm, edc@ALTOS.COM (Eric Christensen) writes: > In article <98@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: > > > >Now that we are starting to get the ELM group whipped into shape, I have > >one problem I want to raise. We are running version 1.5 here and I have > >found that if you send a mail message and then Quit ELM quickly thereafter, > >the message gets killed before it gets spooled up for uucp transmission. > > Ah! Surprise, surprise, surprise! You're /bin/mail (or sendmail, or whatever > you're using for a delivery agent) catches a signal and terminates when it's > parent dies. (Incidently, this is really a very stupid thing for a mail delivery > agent to do :-( ) I've seen this with various versions of Xenix 3.? and V7. I > also have seen it in at least one port of System V. This may be an Elm bug. I seem to remember a patch to Elm 1.7 that fixed a similar problem that occured if you exited Elm and then quickly logged out. Basically, a SIGHUP signal was being sent to the process spawned by Elm, and that signal was not being caught. The fix was to change Elm to ignore the signal (I think). [ ... ] > +-------------------------+---------------------------------------------------+ > | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | > | Altos Computer Systems +---------------------------------------------------+ > | 399 West Trimble Road | Definitions: Bug - An Undocumented Feature | > | San Jose, Ca. 95131 | Feature - A Documented Bug | > +-------------------------+---------------------------------------------------+ > | These views aren't Altos' - They're mine, all mine, and you can't have them | > +-----------------------------------------------------------------------------+ -- Darryl Okahata {hplabs!hpccc!, hpfcla!} hpsrla!darrylo CompuServe: 75206,3074 Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.
edc@ALTOS.COM (Eric Christensen) (06/22/88)
In article <180003@hpsrli.HP.COM> darrylo@hpsrli.HP.COM (Darryl Okahata) writes: >In comp.mail.elm, edc@ALTOS.COM (Eric Christensen) writes: > >> Ah! Surprise, surprise, surprise! You're /bin/mail (or sendmail, or whatever >> you're using for a delivery agent) catches a signal and terminates when it's >> parent dies. (Incidently, this is really a very stupid thing for a mail delivery >> agent to do :-( ) I've seen this with various versions of Xenix 3.? and V7. I >> also have seen it in at least one port of System V. > > This may be an Elm bug. I seem to remember a patch to Elm 1.7 that fixed >a similar problem that occured if you exited Elm and then quickly logged out. >Basically, a SIGHUP signal was being sent to the process spawned by Elm, and >that signal was not being caught. The fix was to change Elm to ignore the >signal (I think). You're right, it was an Elm bug. I got to thinking about it afterwards, and pulled my 1.5 sources off of tape to have a look. Sure enough, 1.5 assumed that the delivery agent was smart enough to finish what it's doing before it exits. This is fine if you have sendmail, but some USG versions of /bin/mail are brain damaged. I'm happy to report that 2.0 takes into account the possibility of a stupid delivery agent. I looked for the patch you mention, but I couldn't find it. That's not to say that there isn't one, just that I don't have it archived anywhere sensible. If someone had that patch lurking around somewhere, could they please repost it? -- +-------------------------+---------------------------------------------------+ | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | | Altos Computer Systems +---------------------------------------------------+ | 399 West Trimble Road | Definitions: Bug - An Undocumented Feature | | San Jose, Ca. 95131 | Feature - A Documented Bug | +-------------------------+---------------------------------------------------+ | These views aren't Altos' - They're mine, all mine, and you can't have them | +-----------------------------------------------------------------------------+
rob@pbhyf.PacBell.COM (Rob Bernardo) (06/23/88)
In article <502@altnet.ALTOS.COM> edc@altnet.UUCP (Eric Christensen) writes: +In article <180003@hpsrli.HP.COM> darrylo@hpsrli.HP.COM (Darryl Okahata) writes: +> This may be an Elm bug. I seem to remember a patch to Elm 1.7 that fixed +>a similar problem that occured if you exited Elm and then quickly logged out. +>Basically, a SIGHUP signal was being sent to the process spawned by Elm, and +>that signal was not being caught. The fix was to change Elm to ignore the +>signal (I think). + +You're right, it was an Elm bug. I got to thinking about it afterwards, and +pulled my 1.5 sources off of tape to have a look. Sure enough, 1.5 assumed +that the delivery agent was smart enough to finish what it's doing before it +exits. This is fine if you have sendmail, but some USG versions of /bin/mail +are brain damaged. + +I'm happy to report that 2.0 takes into account the possibility of a stupid +delivery agent. I wonder if this patch to Elm 1.7 (which I have been using) is causing another problem. At times when I have been in vi under elm and my connection hung up, I'd log back in and see vi (and I think elm) still running. Had a hell of a time trying to kill vi in such a way that my letter under progress could be retrieved with vi -r. Ignoring SIGHUP has its dangers. I don't have the elm source in front of me, but wouldn't it be better for SIGHUP to be ignored only in the /bin/mail fork, so that the parent fork will react appropriately to hang ups? -- Rob Bernardo [backbone]!pacbell!rob -OR- rob@PacBell.COM business: (415) 823-2417 Pacific Bell SRVAC Room 4E750 San Ramon, CA residence: (415) 827-4301 R Bar JB Concord, CA