Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ncar!mailrus!ulowell!page From: page@swan.ulowell.edu (Bob Page) Newsgroups: comp.sys.amiga Subject: moderation Message-ID: <11165@swan.ulowell.edu> Date: 10 Jan 89 21:27:36 GMT Reply-To: page@swan.ulowell.edu (Bob Page) Organization: University of Lowell, Computer Science Dept. Lines: 122 Hey, you were talking about me while I was away! And I thought my ears were burning from the sun... I appreciate everybody thinking about me. Here are some answers, from the mouse's mouth: I repackage everything that doesn't come in the minimal shar, isn't uuencoded with CRCs, doesn't use zoo 1.51 (because that's the latest version available for UNIX, and unix folks have expressed a desire to manipulate these archives), or is split into small or large pieces. I do all the unpacking and packing on swan.ulowell.edu, a VAX-750 that runs 4.3BSD. Soon it will be a MicroVAXII running 4.3-tahoe. When I test the stuff, it's on my Amiga at home, a 2MB A1000 with hard disk and one floppy drive, running a modified KS/WB 1.3. I usually move the code from swan to my amiga via a 2400 bps Zmodem transfer. Since the call is long distance, I try to put the stuff on an A2000 here at ULowell via NFS, but it's a bit of a hassle because I need a floppy (I can never find/remember one) and swan doesn't run NFS, so I have to copy the stuff to another host first. The packing/unpacking procedures I use are not yet automated, I am ashamed to say. I do everything by hand, including naming the files. Many people responded to my request about anims and the like. The response was overwhelming - they do not belong on usenet. However, everybody likes to see them, and would appreciate a way to get at them, via an archive server or anonymous FTP of some kind. So, I'm soliciting sites to archive anims, pictures, songs, whatever. swan.ulowell.edu can't do it; I'm running out of space as it is. I will no longer accept anims/pictures/etc (non-code) larger than 128k, and non-code less than 128k will get pushed to the end of the posting queue. Sure, you can post these monsters to the discussion groups, but I think you'd be more popular if you didn't. People sometimes post code to the discussion groups ("oh, it's small" now replaces "oh, I can't stand the delay"). Just be aware that many folks won't archive your code, so it will probably get re-invented in the future. I never said publicly that I don't test the stuff sent to me. I suppose the large anims that didn't work prove I didn't test those. I test a large amount of stuff, but not everything. So how do you tell what is tested? You don't. I don't consider my job to be tester. As a moderator, here's what I consider to be my responsibilities, in no particular order: 0. Keep discussions out of the groups. 1. Filter copyrighted or duplicate material, or anything otherwise considered not apropos (my judgement, but you haven't heard anybody complaining I rejected their submission, have you?) 2. Make sure it's complete. I reject/return an amazing amount of submissions because the submitter forgot something. I also get a missing header file or a revised .c file a day after the original submission because the author noticed the omission. 3. Make sure sources don't have 8-bit characters in them. I don't like hacking sources & documents, but I'll rip out your c-in-circle character and replace it with (c) if I have to. If there's too many escape sequences for me to deal with, I'll uuencode it. 4. Make sure binaries don't contain the IRQ virus or similar crap. Note I haven't started this yet, but I won't post binary code until I have a scanner. 5. Put the submissions into a 'standard' format. 6. Assign archive index names, for those sites archiving the stuff. 7. Get the submissions out as soon as possible. This is more than you're going to get from a BBS, private or commercial. To the suggestion that I post the minimum hardware and software requirements - I respectfully request you bang on the authors for this info. If they include it, I will include it. To the suggestion that I coordinate a stable of testers - it is the responsibility of the author to test his/her stuff before submitting it, don't you think? I am not running a software testing service. If you want to make sure the stuff works before you spend the time to download it, wait a week or two and find out if anyone has problems. In that amount of time, people will have tested it better than I could have. If any person or group wishes to insert themselves into the pipeline between the submitter and me, announce it to the world and have the authors send you code to test. When the author is satisfied that the testers have given it a clean bill of health, s/he can send it to me and I will do all the things I described above. I, however, will not send submissions to a clearinghouse first. I will repeat that I test much of the stuff, but not everything, and everything that IS tested gets tested at different levels. That's why I don't say "this is tested" and "this isn't tested". I am not being inflexible. I have radically changed the way I package the code because of comp.sys.amiga input, and I will continue to encourage suggestions on how I can make the source/binary distribution service better. However, I will tell you now: I will never say "I tested this". Finally, if any person or group is dissatisfied with the moderation and wants to take on the job [and the rest of the group thinks it's a Good Thing], I will gladly hand it over. I have posted 59 source packages and 64 binary packages, many in multi-parts and some more than once (different versions), in less than three months. There has been little complaining about stuff not working, and only now because somebody spent hours downloading an enormous anim that didn't work. I won't be posting those anymore. I think testing is a non-issue. If you don't, do something about it. Your humble servant, ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.