hack@bellboy.UUCP (Greg Hackney) (06/10/88)
While we are killing some time waiting for the big vote, I'd like to open up some general discussion on the future releases of Elm.... In general, the way it has worked in the past, is one person wrote the software and collected the bugs. After a sufficient number of bugs were corrected, enhancements added etc., a new issue of Elm came out, i.e. version 1.7. This caused a problem for me. I had a number of bugs that had to be resolved immediately, or my boss and the users would hang me. So, I tended to hack Elm on my own. I, being a slug, didn't put it under SCCS control. So, it is always real hairy for me to go to a new release. And, a lot of other users are in the same shape, they have a mutant version of Elm. It seems to me that the group should not procrastinate in getting these bugs fixed and released immediately. To do this, I like the idea of how the readnews (rn) program is issued. That is, just issue a patch file, instead of collecting a gob of fixes and waiting for a major release. I don't care if it goes to patch level 1000, as long as I can go to an archive site and readily get the main issue and all the patches. (And, I like the idea of releasing everything officially through comp.sources.unix via Rich Salz.) I know that David Taylor had to spend a lot of his time doing development work on Elm, plus his real work, and I think I understand some of his philosophy on releases. But, as a group project, I think we can get the product out the door a lot faster, and I think we MUST in order for the users to keep current..... One thing that is debatable, is whether or not the subscribers ought to post bug reports and fixes, or whether to not post them but to send them directly to a coordinator. I personally think we should openly post everything. That way, the expertise of the entire newsgroup is available as a resource, rather than just that of the coordination and test committee. We are trying to get Elm going as a newsgroup project, rather than a single effort. The end user will have to be responsible for maintaining their own intermediate hacks for themselves. But if patches are handled in a timely manner, I don't see much of a problem. I do see it as a problem to quietly hoard the fixes, and I see it as a problem if the Elm community does not know everything that is going on. The Elm postings are saying, "When is such and such going to happen", because they really are in the dark as to the underworkings. If we all post openly, then everyone will know at the same time. We will all be informed. -- Greg
edc@ALTOS.COM (Eric Christensen) (06/10/88)
In article <1095@bellboy.UUCP> hack@bellboy.UUCP (Greg Hackney) writes: > >It seems to me that the group should not procrastinate in getting >these bugs fixed and released immediately. To do this, I like the >idea of how the readnews (rn) program is issued. That is, just >issue a patch file, instead of collecting a gob of fixes and >waiting for a major release. Ah! Excellent idea! I was going to suggest the same thing. The patch system works real well for a distributed project like this. And to make it even easier, if the master (meaning the coordinators) sources are under RCS it's real, real easy to maintain with rcsdiff(1) and rcsmerge(1). >I don't care if it goes to patch level >1000, as long as I can go to an archive site and readily get the main >issue and all the patches. (And, I like the idea of releasing everything >officially through comp.sources.unix via Rich Salz.) I feel that the coordinator should set up a master archive with anonymous uucp. That way we can keep everybody that's actually working on Elm (as opposed to just using it) up to date. There's nothing more frustrating than creating a patch, and discovering that in the mean time another patch came out which affects yours, but you don't have it! If, for some reason, the duly elected coordinator cannot set up annonymous uucp, I'd be more than happy to set it up off altnet (assuming that I'm not the duly elected coordinator). >One thing that is debatable, is whether or not the subscribers >ought to post bug reports and fixes, or whether to not post them >but to send them directly to a coordinator. I personally think >we should openly post everything. That way, the expertise of the >entire newsgroup is available as a resource, rather than just that >of the coordination and test committee. We are trying to get Elm >going as a newsgroup project, rather than a single effort. Certainly everything that is "officially" released should be posted to comp.sources.unix! I don't particuarly like getting a whole load of patches for a program (like rn) only to find that one of them in the middle doesn't work right though. As an alternative (read: "happy medium"), let's post patches to comp.mail.elm so that they can be tested by the test group, and retrieved by anyone else who is really interested. Then, once the test group gives the blessing, the coordinator should make an official patch release to comp.sources.unix. In some cases, we could even merge multiple patches into one posting to simplify things for the poor guys on the other end (and Rich Salz too.). Additionally, let's set up a mailing list of some sort for the testers and developers. That way we can ensure that everybody knows what's going on all the time. The "pre-test" patches could be mailed to the testers and developers also. -- +-------------------------+---------------------------------------------------+ | 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 | +-----------------------------------------------------------------------------+
rsk@s.cc.purdue.edu (Rich Kulawiec) (06/11/88)
In article <1095@bellboy.UUCP> hack@bellboy.UUCP (Greg Hackney) writes: >This caused a problem for me. I had a number of bugs that >had to be resolved immediately, or my boss and the users would >hang me. So, I tended to hack Elm on my own. I, being a slug, didn't >put it under SCCS control. So, it is always real hairy for me to >go to a new release. I strongly recommend using the facilities of a source code control system such as SCCS or RCS; it makes upgrading to new releases much, much easier at the expense of some initial learning and setup time. Random hacking of sources leads to a state of entropy in the source directory that I find undesirable. Incidentally, we use RCS; I guesstimate that it will take us about half an hour to bring in 2.0 and apply all of our local changes (which were made to 1.7) to it, and most of the process will be automated. >(And, I like the idea of releasing everything >officially through comp.sources.unix via Rich Salz.) > >One thing that is debatable, is whether or not the subscribers >ought to post bug reports and fixes, or whether to not post them >but to send them directly to a coordinator. I personally think >we should openly post everything. This would create several problems: 1. It will make it difficult to correctly identify patches by number (and thus to identify the release number of the version of Elm so generated). For instance, if you and I release patches simultaneously, is mine #7 or is yours? What version of Elm is thus generated, 2.0.7 or 2.0.7.and.the.other.7? Sequencing the patches through a coordinator prevents this from happening. 2. If you're going to send these things through Rich Salz, and thus to comp.sources.unix, you're much better off having them pre-organized before shipping them. I don't purport to speak for Rich, but it seems to me that he'd much rather receive bundled, well-organized patch sets from a single person than scattered random changes from numerous people. Again, having a coordinator avoids this problem. 3. It is likely that some problems will have more than one solution; it's also likely that some of those solutions will be incompatible. Someone, unfortunately, must choose which solution is best for everyone, or else the software will diverge at different sites. To avoid endless argument, it would probably be best to have someone (who is qualified and interested) resolving conflicting changes. In view of these considerations, I strongly recommend the use of a central clearinghouse for changes to Elm. -- Rich Kulawiec, rsk@s.cc.purdue.edu, s.cc.purdue.edu\!rsk PUCC Unix Staff
syd@dsinc.UUCP (Syd Weinstein) (06/12/88)
Greg proposed posting patches openly, I have to counter`
I agree with using patches, but not open posting of them. I feel
the patches should be moderated by the coordinator.
I say so for the following reasons:
1. This will avoid multiple patches for the same issue.
2. Many patches might involve machine specific code. The poster
might not notice this problem, however the coordinator would be more
likely to.
3. A patch might conflict with a development problem, the coordinator
might be able to change the patch or ask the patch author to change it
to accomplish the same thing without stepping on future development.
4. Although the patch poster is doing us all a favor, not all net
posters are equal level programmers. Some patches might be poor
programming that will limit elm or introduce side effects.
The coordinator could use his/her judgement in looking at the patch.
I have seen many 100 line patches to some software I manage that could
easily have been done with a two line change. The problem was that
the author didnt see the forest for the trees. I may be flamed for this
but most bugs require simple changes. If a major change is needed,
perhaps the module should be rewritten for a future release.
5. The coordinator can the make sure that official patches are
incorporated into future releases and can also mark such patches
as official so everyone knows that they will not have to back
them out by hand for the next official patch. (Note how
Larry Wall issues official patches this way.)
Anyway, my $.02, and I am willing to do it that way.
As for another topic about elm coordinators while I am posting,
I do not feel we need both and RCS and an SCCS tree. One or the other
will do. As long as the coordinator checks in and out modules for
editing by the developers, only one tree is needed. I use SCCS here
due to history reasons (We have used unix since PWB was released and
PWB had SCCS). One feature we need to use within SCCS is the
branch delta. This will allow bug fixes to current releases as well
as future development. We use this method on several large projects
here at Datacomp Systems, Inc.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP
Datacomp Systems, Inc. Voice: (215) 947-9900
{allegra,bellcore,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235hack@bellboy.UUCP (Greg Hackney) (06/12/88)
In article <3159@s.cc.purdue.edu> rsk@s.cc.purdue.edu.UUCP (Rich Kulawiec) writes: >I strongly recommend using the facilities of a source code control >system such as SCCS or RCS; Yes, it's a very basic requirement! >>One thing that is debatable, is whether or not the subscribers >>ought to post bug reports and fixes, or whether to not post them >>but to send them directly to a coordinator. >This would create several problems: > >1. It will make it difficult to correctly identify patches by >number (and thus to identify the release number of the version >of Elm so generated). For instance, if you and I release >patches simultaneously, is mine #7 or is yours? No no, I agree with you. There were some folks saying that if we found a bug, to not post that finding, but to send it to a coordinator. I meant, yes, let's send it to a coordinator, but also post our findings to keep others abreast of what's going on. The coordinator should definitely be in full control of the official patch releases. And only the coordinator and testers should have access to the preliminary official patch. But as a normal user, I would want to know of the bug report and basic fix as soon as possible, so I could apply a temporary fix on my own if I so desired. Reasonable? -- Greg
hack@bellboy.UUCP (Greg Hackney) (06/12/88)
In article <419@altnet.ALTOS.COM> edc@altnet.UUCP (Eric Christensen) writes: >Certainly everything that is "officially" released should be posted to >comp.sources.unix! Yes, I believe it gets automatic distribution to ftp and uucp archive sites that way. But, perhaps the patches can be posted in both groups since they are normally small. >As an alternative (read: "happy medium"), let's post patches >to comp.mail.elm so that they can be tested by the test group The newsgroup shouldn't be the test group. please read on... >Additionally, let's set up a mailing list of some sort for the testers and >developers. Yes, I think the testers and coordinators should set up a private mailing list for tossing ideas and patch code around. comp.mail.elm should only be involved at 2 points in time. Once when the user reports a bug or possible fix, and once when the patch is released. A lot of source code is delayed by Rich $alz while he checks it out. But, he should be able to get it out the door right away on the approval of the Elm coordinator. -- Greg
mike@ists.yorku.ca (Mike Clarkson) (06/13/88)
In article <419@altnet.ALTOS.COM>, edc@ALTOS.COM (Eric Christensen) writes: > Let's post patches > to comp.mail.elm so that they can be tested by the test group, and retrieved > by anyone else who is really interested. Then, once the test group gives the > blessing, the coordinator should make an official patch release to > comp.sources.unix. In some cases, we could even merge multiple patches into > one posting to simplify things for the poor guys on the other end (and Rich > Salz too.). Everyone can post comments and patches here, and periodically the coordinator can post official patches. Just like news - I look at everyone elses patches to news, but unless it's crucial, I wait for the "official" patches. > Additionally, let's set up a mailing list of some sort for the testers and > developers. That way we can ensure that everybody knows what's going on > all the time. The "pre-test" patches could be mailed to the testers and > developers also. I don't think this is really necessary. Comp.mail.elm is very low volume and we can carry on discussions here quite easily. Besides it avoids a lot of grief that comes with trying to maintain mailing lists. Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
edc@ALTOS.COM (Eric Christensen) (06/14/88)
In article <144@ists> mike@ists.yorku.ca (Mike Clarkson) writes: >In article <419@altnet.ALTOS.COM>, edc@ALTOS.COM (Eric Christensen) writes: >> Let's post patches >> to comp.mail.elm so that they can be tested by the test group, and retrieved >> by anyone else who is really interested. Then, once the test group gives the >> blessing, the coordinator should make an official patch release to >> comp.sources.unix. In some cases, we could even merge multiple patches into >> one posting to simplify things for the poor guys on the other end (and Rich >> Salz too.). > >Everyone can post comments and patches here, and periodically the coordinator >can post official patches. Just like news - I look at everyone elses >patches to news, but unless it's crucial, I wait for the "official" patches. Exactly! There is going to be some delay (hopefully < 1 week) getting patches tested and checked into the RCS (SCCS?) tree. If I'm having a problem which is seriously effecting my installation, and someone has a patch for it, then I want it. I'm willing to take the risk of an untested patch, and likewise, spend the extra effort to remove that patch when an offical one comes out. But the bottom line is that it's MY option. I can use it, or I can wait for the coordinator to post the real thing. > >> Additionally, let's set up a mailing list of some sort for the testers and >> developers. That way we can ensure that everybody knows what's going on >> all the time. The "pre-test" patches could be mailed to the testers and >> developers also. > >I don't think this is really necessary. Comp.mail.elm is very low volume >and we can carry on discussions here quite easily. Besides it avoids >a lot of grief that comes with trying to maintain mailing lists. True, comp.mail.elm is low volume, and it is a pain to maintain a mailing list, but I don't think we really want the developers and testers sending crap back and forth via the news group. Especially new code which hasn't been tested yet. For example, I'm working on several network related enhancements, and a couple of user interface enhancements. I do want the developers to know what I'm up to, and I do want the testers to check my stuff out before I release it to the world. But I don't want half implemented code going out to the world. Does this make any sense at all? Or have I been smoking too much "source code tightly wrapped in 96 column punched cards" ???? Enough mindless dribble for one posting... :-) -- +-------------------------+---------------------------------------------------+ | 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 | +-----------------------------------------------------------------------------+
hann@rd1632.Dayton.NCR.COM (Ed Hann) (06/15/88)
In article <144@ists> mike@ists.yorku.ca (Mike Clarkson) writes: > >Everyone can post comments and patches here, and periodically the coordinator >can post official patches. Perhaps the coordinator could collect the unofficial patches, store them in there original posting form for anybody to retrieve via uucp. He could maintain original code and official patches separately, also available for retrieval via uucp. He could periodically post info on where to get them in case a user misses an original posting or to help new readers. All code: original, unofficial patches, and official patches; is always available to anybody via uucp. >> Additionally, let's set up a mailing list of some sort for the testers and >> developers. That way we can ensure that everybody knows what's going on >> all the time. The "pre-test" patches could be mailed to the testers and >> developers also. > Good idea, if it would help the coordinator keep the testers together. Ed Hann (Ed.Hann@Dayton.NCR.COM) Applied Research, R&D Division or NCR Corp., World Headquarters, 5/E (Ed.Hann%Dayton.NCR.COM@RELAY.CS.NET) Dayton, Ohio 45479 513 445-1061
nate@mipos3.intel.com (Nate Hess) (06/17/88)
In article <1095@bellboy.UUCP> hack@bellboy.UUCP (Greg Hackney) writes: >One thing that is debatable, is whether or not the subscribers >ought to post bug reports and fixes, or whether to not post them >but to send them directly to a coordinator. I personally think >we should openly post everything. My 2 cents: Posting bug reports is a good idea. Posting fixes is a good idea. But there should be Official patches and Official posts of those patches. The idea of having coordinators is to avoid everyone having their own personally hacked up version of Elm. Post fixes, yes; encourage people to test out posted fixes and post new and improved fixes, yes; however, *always* ensure that the coordinators are the ones to send out official patches and new releases. --woodstock -- "How did you get your mind to tilt like your hat?" ...!{decwrl|hplabs!oliveb|pur-ee|qantel|amd}!intelca!mipos3!nate <domainish> : nate@mipos3.intel.com ATT : (408) 765-4309