Xref: utzoo comp.sys.amiga.advocacy:4041 comp.sys.amiga.programmer:4644 comp.sys.amiga.misc:4688 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!att!pacbell.com!tandem!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga.advocacy,comp.sys.amiga.programmer,comp.sys.amiga.misc Subject: Re: Another Amiga reorganization needed? Summary: Re: LISP mail list and: Another Amiga reorganization needed? Message-ID: <1991Jun18.092655.12436@zorch.SF-Bay.ORG> Date: 18 Jun 91 09:26:55 GMT References: <1991Jun16.014324.532@zorch.SF-Bay.ORG> Organization: SF-Bay Public-Access Unix Lines: 165 sutela@polaris.utu.fi (Kari Sutela) wrote: > comp.sys.amiga.programmer.asm > Assembly related programming. There currently > seems to be quite a lot of people who would read > this group. Those of us (me, for example) who > don't know a LEA from a CMP could unsubscribe to > it without regrets. xanthian@zorch.sf-bay.org (Kent Paul Dolan) wrote: > Well, if we go language oriented, we need to cope > with C, Modula-2, Fortran, Lisp/Scheme/Xlisp, > Draco, AmigaBASIC, AREXX, and probably several > other popular Amiga languages that don't come to > mind immediately. I left out C++; imminent brain death detected. mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) wrote: > How about > comp.sys.amiga.programmer.{asm,arexx,c,misc}? That > covers the big three, and leaves a place for > everything else. I would have included m2, but you > said that the mail list isn't very active, and I > don't know how it compares to the various basics. Only real problem I have with "by language" split is that you'd probably divide the traffic 10-5-80-5, and 80% of comp.sys.amiga.programmer is still too damn big. I'm still looking for a good breakdown; I don't much like mine, or any I've seen yet either; on the other hand, I like some of the stuff proposed for .hardware quite a bit. I need more help for ways to filter off stuff for .misc that is big enough to constitute a separate focus of traffic, but isn't just misplaced for a group that already exists. I'd be happy with even a four way split for c.s.a.programmer, but only if the smallest part of the split was 20% or more; anyone have any ideas or willing to do a subject analysis? What I'd _really_ like is a set of "get this stuff out of my face" proposals like the c.s.a.p.asm one Kari gave above, for substantial chunks of traffic folks would rather not read. While it's on my mind, is there any support for trying to move alt.sys.amiga.uucp{,patches} into the mainstream hierarchy, or is the alt distribution sufficient for such a narrow focus? After being scolded twice in email, I'll concede that c.s.a.prog-* and c.s.a.hdwr-* are ugly enough names that c.s.a.programm{er,ing}.* and c.s.a.hardware.* should be the choices, and I'll concede defeat on trying to keep c.s.a.* a flat hierarchy. Also, Peter da Silva would like to pull the Amiga futures discussion out of .advocacy, where it drowns in 90% or so flames; I'm willing to do it iff the group is moderated; otherwise the flames will just follow the discussion. Peter says two kids and work overload keep him unavailable; any volunteers to moderate c.s.a.futures if we make one? Mike, if you're back from Usenix, do you still want a group of your own? Another fairly coherent proposal received in email [heavily edited and mildly commented:] Darren Ewaniuk wrote: [about my hardware split:] > In my opinion (I'm an EE specializing in hardware > design) these splits aren't logical at all. > c.s.a.h.design is about the only logical split > from this, and there is low traffic on this. And > imagine the strain that poor Dave Haynie would be > under, as he'd practically be running this group! > c.s.a.problems would remove the need for your > 3rd-party and standard groups. > About the best split here would be to split off > the problems section (My brand x HD controller > won't work with rev y.y motherboard with brand z > memory board. What can I do?) into c.s.a.problems > or c.s.a.h.problems (although I prefer > c.s.a.problems) Actually, I like this a lot; a split into comp.sys.amiga.hardware.{misc,problems} would probably be close to 50-50, and might be "good enough" folks seeking (or willing to offer) help could be one place, folks just chatting about hardware issues in the other, and this may well provide two groups that can mostly ignore one another. > In short, my proposals are: > New groups: > comp.sys.amiga.problems - catch all for hardware and otherwise > -or- generic software problems. > comp.sys.amiga.hardware.problems - If you only want hardware problems. I much prefer the second; see below. > comp.sys.amiga.system - Good idea for kickstart/WB/system > discussion. > Split from comp.sys.amiga.programmer: > comp.sys.amiga.programmer.c - C specific discussion. > comp.sys.amiga.programmer.asm - Assembly specific discussion. > comp.sys.amiga.programmer.problems - Programming problems with system > routines or other languages. This strongly suggests c.s.a.hardware.problems, just to keep it from getting filled with "miscellaneous" problems by folks who don't notice the c.s.a.programmer.problems group. > Keep comp.sys.amiga.hardware and > comp.sys.amiga.programmer intact. Sort of; they'll both end up with .misc tags for reasons of net neatness. > These will still be the 'catch all' type of > groups, but will have their volume cut a bit by > splitting off some identifiable traffic into > comp.sys.amiga.problems, > comp.sys.amiga.programmer.problems, > comp.sys.amiga.programmer.c, and > comp.sys.amiga.programmer.asm. I'm still worried about the size of the .c portion, but let's hear what other people think. > [permission granted to summarize and post if any > of these make sense] Enough to be worth presenting publically. Any input on what to do with C++? Quite a bit of traffic now, likely to grow fast, as it is a popular language, and we finally have an up-to-date implementation available. /// It's Amiga /// for me: why Kent, the man from xanth. \\\/// settle for \XX/ anything less? -- Convener, COMPLETED comp.sys.amiga grand reorganization.