brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/30/90)
It's difficult to know what it really takes to moderate a major source group until you've spent some time at the job. But I'll bet that if there's one thing that will take the load off Rich's back, it's seeing on a small scale what will happen when a package appears. You want comp.sources.unix to produce software faster? You want to contribute some effort? Stop whining and start beta testing! I'd like to help. If Rich sends me each comp.sources.unix submission at some stage of editing, I'll do my best to look at and test at least half the packages in each volume. I'll tell Rich what I think about each package, and I'll follow any guidelines he sets on things to look for. I'll tell him if I ever find I no longer have the time or resources to keep up with his schedule. Do you want to help? Do you want to see comp.sources.unix submissions ahead of time, and help give each package the workout it deserves? Say so. Follow up to this message and make a commitment. Disclaimer: I haven't checked with Rich, so I don't know whether he supports this idea. ---Dan
jfh@rpp386.cactus.org (John F. Haugh II) (11/30/90)
In article <10770:Nov3009:18:4790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >You want comp.sources.unix to produce software faster? You want to >contribute some effort? Stop whining and start beta testing! This is a fantastic idea. >I'd like to help. If Rich sends me each comp.sources.unix submission at >some stage of editing, I'll do my best to look at and test at least half >the packages in each volume. I'll tell Rich what I think about each >package, and I'll follow any guidelines he sets on things to look for. >I'll tell him if I ever find I no longer have the time or resources to >keep up with his schedule. I think a better idea would be a list of volunteers whom Rick distributes a list of packages amongst. The volunteers then request the packages they are able to/interested in testing. This way people who have resources to spare can sign up for more work than those people without. Anyone who gets burnt out naturally fades into the woodwork. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "SCCS, the source motel! Programs check in and never check out!" -- Ken Thompson
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/01/90)
In article <18766@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: > The volunteers then request the packages they > are able to/interested in testing. This way people who have resources > to spare can sign up for more work than those people without. Okay, the exact organization of this thing can be debated (and is really up to Rich). Other people have likened comp.sources.unix to a technical journal whose editor might appreciate some referees. But however you want to look at it, the most constructive way to contribute to comp.sources.unix is to volunteer your services as a beta tester. ---Dan
marz@cbnewsm.att.com (martin.zam) (12/01/90)
In article <10770:Nov3009:18:4790@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > You want comp.sources.unix to produce software faster? You want to > contribute some effort? Stop whining and start beta testing! > > Do you want to help? Do you want to see comp.sources.unix submissions > ahead of time, and help give each package the workout it deserves? Say > so. Follow up to this message and make a commitment. > > Disclaimer: I haven't checked with Rich, so I don't know whether he > supports this idea. > > ---Dan I'm just as swamped as the next guy, but if a bunch of us overworked hacker types would each pick up just one package and apply some small amount of the time we might otherwise spend playing computer games (you know who you are), we could see this problem solved in a very net-like manner. Look, I spend time playing with code I get from the net anyway. I like the idea of other people getting some benefit of the time I invest in getting these programs into a useful form. So count me in. I'll invest the time I usually do anyway, maybe more if I know people are waiting for me to finish. Hope this influences a few, Martin Zam (201)564-2554
rodgers@clausius.mmwb.ucsf.edu (12/01/90)
In <18766@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >In article <10770:Nov3009:18:4790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >>You want comp.sources.unix to produce software faster? You want to >>contribute some effort? Stop whining and start beta testing! >This is a fantastic idea. >I think a better idea would be a list of volunteers whom Rick distributes >a list of packages amongst. This is definitely worth pursuing. The idea is similar to that of a peer-reviewed journal, with its Board of Editors. As frustrated as i have been with the slowness in comp.sources.unix, my sympathies lie with Rich; this is an enormous amount of work for one busy professional to be doing in his/her fleeting spare moments (thanks, Rich!). I don't know how any of the source moderators do it. It would indeed be better if we all stopped whining and looked at new ways of doing things. Given the loose organization of the net, perhaps one source group adapting this structure would lead to others following. Cheerio, Rick Rodgers R. P. C. Rodgers, M.D. (415)476-8910 (work) 664-0560 (home) UCSF Laurel Heights Campus UUCP: ...ucbvax.berkeley.edu!cca.ucsf.edu!rodgers 3333 California St., Suite 102 ARPA: rodgers@maxwell.mmwb.ucsf.edu San Francisco CA 94118 USA BITNET: rodgers@ucsfcca
brendan@cs.widener.edu (Brendan Kehoe) (12/01/90)
In article <1990Nov30.182303.19373@cbnewsm.att.com>, marz@cbnewsm.att.com (martin.zam) writes: > In article <10770:Nov3009:18:4790@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > You want comp.sources.unix to produce software faster? You want to > > contribute some effort? Stop whining and start beta testing! > I'm just as swamped as the next guy, but if a bunch of us overworked > hacker types would each pick up just one package and apply some > small amount of the time we might otherwise spend playing computer > games (you know who you are), we could see this problem solved in a > very net-like manner. I also agree with this idea .. I think that things would really fly if such a thing were set up. (I'm also willing to help in it.) -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester PA A Bloody Sun-vs-Dec War Zone UN: "You can open the new toys on Jan 15th." Bush: "Oh boy oh boy, *really*?"
tar@math.ksu.edu (Tim Ramsey) (12/01/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Do you want to help? Do you want to see comp.sources.unix submissions >ahead of time, and help give each package the workout it deserves? Say >so. Follow up to this message and make a commitment. Okay, I volunteer to help out. I know my way around a UNIX system, I have free time, and best of all I know the system administrator on this system will let me. Tim -- Tim Ramsey (tar@math.ksu.edu) (913) 532-6750 (voice) 532-7004 (FAX) Department of Mathematics, Kansas State University, Manhattan KS 66506 -- Of course, if the 35th Division gets activated, my free time will -- go away very quickly. :-(
ronald@robobar.co.uk (Ronald S H Khoo) (12/01/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > Okay, the exact organization of this thing can be debated (and is really > up to Rich). One problem is that r$ doesn't often like to discuss what/why/how he's managing with c.s.u. This isn't the first time that people have offered to help in a public forum, but I don't think r$ has ever taken anyone up on their offers. I don't know if it's a good thing or a bad thing (at least with r$ we know who we're getting) but it does seem that r$'s silence does seem to bring out all sorts of nasty comments from some people. -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
pjg@acsu.buffalo.edu (Paul Graham) (12/01/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |Do you want to help? Do you want to see comp.sources.unix submissions |ahead of time, and help give each package the workout it deserves? Say |so. Follow up to this message and make a commitment. i admire this action but this really isn't a new idea. and i think it puts the cart before the horse. it seems we should have a framework to operate in before we start planning the operation. at the very least rich should tell us if he thinks this is a good idea. if there is sufficient support for a new way to deliver unix sources then a call for discussion and vote for a new group should be simple if comp.unix.sources is felt to be deficient in some way and nothing is going to change. we could call it comp.sources.unix.refereed. -- pjg@acsu.buffalo.edu / rutgers!ub!pjg / pjg@ubvms (Bitnet) opinions found above are mine unless marked otherwise.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/02/90)
As quoted from <10770:Nov3009:18:4790@kramden.acf.nyu.edu> by brnstnd@kramden.acf.nyu.edu (Dan Bernstein): +--------------- | Do you want to help? Do you want to see comp.sources.unix submissions | ahead of time, and help give each package the workout it deserves? Say | so. Follow up to this message and make a commitment. +--------------- I don't know about Rich, but *I* like it --- and it has the further advantage that, with enough willing volunteers on enough different machines/operating systems, one can then test almost any package that comes in by shunting it to the right volunteer for testing. Maybe the next moderator of .misc should try this out. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
scs@lokkur.dexter.mi.us (Steve Simmons) (12/02/90)
pjg@acsu.buffalo.edu (Paul Graham) writes: >it seems we should have a framework >to operate in before we start planning the operation. at the very >least rich should tell us if he thinks this is a good idea. >if there is sufficient support for a new way to deliver unix sources >then a call for discussion and vote for a new group should be simple >if comp.unix.sources is felt to be deficient in some way and nothing >is going to change. >we could call it comp.sources.unix.refereed. Paul has summed it all up in a few sentences. For a discussion that started as a flamefest it'd (what's the opposite of degenerated?) become a remarkably constructive ideafest. Much as I respect Rich, I don't see where his input is required. Any 'comp.sources.refereed' will be a new way of doing source examination, and should be looked on as such. Yes, there will be some competition or overlap, but that's fine. The net evolves by practical experiment, as it should. All we need is a few acceptable volunteers for editor and some policy for the charter. Exact details of how to edit/moderate/referee should be up to the editor and the reviewers. -- "I was talking about what it takes to be a real critic, not a critic wannabe." -- Mike Godwin, rec.arts.comics critic
edguer@charlie.CES.CWRU.Edu (Aydin Edguer) (12/02/90)
In article <1990Dec1.214721.15514@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: >As quoted from <10770:Nov3009:18:4790@kramden.acf.nyu.edu> by brnstnd@kramden.acf.nyu.edu (Dan Bernstein): >+--------------- >| Do you want to help? Do you want to see comp.sources.unix submissions >| ahead of time, and help give each package the workout it deserves? Say >| so. Follow up to this message and make a commitment. >+--------------- > >I don't know about Rich, but *I* like it --- and it has the further advantage >that, with enough willing volunteers on enough different machines/operating >systems, one can then test almost any package that comes in by shunting it to >the right volunteer for testing. Maybe the next moderator of .misc should try >this out. Okay. Rich $alz usually requires the following to publish a source. 1) a makefile 2) documentation 3) a manual page 4) it works (at least compiles) on the moderators machine What are you now talking about adding? I assume you want to test the program on the different variants of UNIX. What is the "minimum" subset? BSD4.2, BSD4.3, BSD4.3Tahoe, BSD4.3Reno, SVR2, SVR3, XENIX, XENIX 286, SVR4, ULTRIX, SunOS, HP-UX, UNICOS, OSF/1, BSD2.10? So, lets say that the program does not work under System V. Does the source not get published? Does the source get published but with a warning? Let's say that the moderators find some compatibility problems. Do they send the changes back to the author? Do they make up patches and send them along with the source? What if an author decides that they do not want to support the software on systems they do not have access to? Do the moderators release "unofficial" patches? What if one of the moderators does not finish testing within the one or two week limit for processing? Does the whole posting get held up? Does the posting get made but with a message saying it is untested under XYZNIX? Should list of moderators be limited to people with Internet connections? Do moderators have to test out future patches in addition to the sources? I really do like the idea, but I don't see answers to all the problems and am wondering what people think. Or am I blowing things out of proportion? -- Aydin Edguer
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/03/90)
In article <1990Dec2.013833.13194@usenet.ins.cwru.edu> edguer@charlie.CES.CWRU.Edu (Aydin Edguer) writes: > Okay. Rich $alz usually requires the following to publish a source. > 1) a makefile > 2) documentation > 3) a manual page > 4) it works (at least compiles) on the moderators machine > What are you now talking about adding? This is orthogonal to the requirements. It's just something to ease the burden on Rich of portability testing. > I assume you want to test the program on the different variants of UNIX. > What is the "minimum" subset? BSD4.2, BSD4.3, BSD4.3Tahoe, BSD4.3Reno, SVR2, > SVR3, XENIX, XENIX 286, SVR4, ULTRIX, SunOS, HP-UX, UNICOS, OSF/1, BSD2.10? Whatever testers provide is good. > So, lets say that the program does not work under System V. Does the source > not get published? Does the source get published but with a warning? What currently happens is that most sources get published with a list of machines they've been tested on. When a new version is sent out, the author adds to the list anything people tell him about. Now the extra testing would just be a small-scale rendition of what happens when the software is posted. So if the author hears ``it doesn't work under System V,'' he might say ``I knew that, README says it's only for BSD,'' or ``Oh, whoops, let me try to fix that before we go ahead,'' or ``I didn't realize it wasn't portable---please add it to the bottom of README.'' This is exactly what happens for user comments now. > Let's say that the moderators There's only one moderator, namely Rich. As a tester I'd do exactly what I do when I see a package posted: bring it up on the most ``standard'' machine I can find (a Sun 4 running SunOS 4.0.3), and see what I think. If it shows any promise I'll try it on other machines. This is a lot less work than what goes into moderation---checking for sanity, making improvements, dealing with a huge number of mail messages, and posting software that people can trust. > find some compatibility problems. Do they > send the changes back to the author? Do they make up patches and send them > along with the source? As above, information goes back to the author. Sure, patches help. > What if an author decides that they do not want to support the software on > systems they do not have access to? Do the moderators release "unofficial" > patches? If the testers want to post unofficial information about a package, they can (though they should wait for the final version in case there are more changes). As always, the author makes the final decision about what his package should contain. > What if one of the moderators does not finish testing within the one or two > week limit for processing? Does the whole posting get held up? A tester who can't get back to Rich in a reasonable time won't get any more software. > Does > the posting get made but with a message saying it is untested under XYZNIX? It's usually stated positively: ``This package has been tested under these systems...'' Someone with XYZNIX will, of course, be more confident in a package that has already been tested under XYZNIX than with one that's only been tested with the older versions, XNIX and XYNIX, or with competitor ZYXNIX. > Should list of moderators be limited to people with Internet connections? Why? > Do moderators have to test out future patches in addition to the sources? Do you have to install every future version of a program you use? It's less work than the first time, but except for major programs like news where you have to interoperate with the rest of the world, there's no need. And lots of sites never seem to upgrade news... Before I send code to Rich or anywhere else, I try it out on a small scale. People bang on it for a while, and I use their comments to improve it. This would just be a slightly bigger next step. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/03/90)
In article <1990Dec1.231725.28103@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: > Much as I respect Rich, I don't see where his input is required. Any > 'comp.sources.refereed' will be a new way of doing source examination, > and should be looked on as such. I don't know about you, but I want somebody with experience moderating the most useful group on the Internet. I also wouldn't mind beta-testing packages that come through, so as to give Rich and the authors a bit more assurance that the code is portable. If Rich likes the idea of having testers, your proposal for comp.sources.refereed will fall flat. Why are you so eager to institute major changes in a system that works? ---Dan
scs@lokkur.dexter.mi.us (Steve Simmons) (12/03/90)
scs@lokkur.dexter.mi.us (That's Me!) writes: > Much as I respect Rich, I don't see where his input is required. Any > 'comp.sources.refereed' will be a new way of doing source examination, > and should be looked on as such. brnstnd@kramden.acf.nyu.edu (Dan Bernstein) responds: >I don't know about you, but I want somebody with experience moderating >the most useful group on the Internet. I also wouldn't mind beta-testing >packages that come through, so as to give Rich and the authors a bit >more assurance that the code is portable. If Rich likes the idea of >having testers, your proposal for comp.sources.refereed will fall flat. >Why are you so eager to institute major changes in a system that works? Paul Grahams original comment (which I quoted) was: it seems we should have a framework to operate in before we start planning the operation. at the very least rich should tell us if he thinks this is a good idea. I'd be most pleased to have Rich's comments. Please note I said his input is not *required*. For whatever reason he is not participating in this discussion. That lack of participation should not prevent us from going ahead with Pauls excellent idea. Note too, that a refereed newsgroup is going to be quite a different beast to manage. Richs experinces (and Brandons, and anybody else who's been moderating a source groups) will be most useful to the referees. Overseeing the referees is something few if any of us have experince with. -- "I was talking about what it takes to be a real critic, not a critic wannabe." -- Mike Godwin, rec.arts.comics critic
kent@sparky.IMD.Sterling.COM (Kent Landfield) (12/04/90)
In article <10770:Nov3009:18:4790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >You want comp.sources.unix to produce software faster? You want to >contribute some effort? Stop whining and start beta testing! This is a great idea! >I'd like to help. And so would I... We have been seeing this line focused mainly on c.s.u. Maybe there are other source group moderators who might want to consider this. Everyone wins with this approach. >Do you want to help? Do you want to see comp.sources.unix submissions >ahead of time, and help give each package the workout it deserves? Say >so. Follow up to this message and make a commitment. Done! Any source moderator who would like to try this idea out, send me some email. I'll help. -Kent+ -- Kent Landfield INTERNET: kent@sparky.IMD.Sterling.COM Sterling Software, IMD UUCP: uunet!sparky!kent 1404 Ft. Crook Rd. South Phone: (402) 291-8300 Bellevue, NE. 68005-2969 FAX: (402) 291-4362
irick@en.ecn.purdue.edu (GarBear Irick) (12/04/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Do you want to help? Do you want to see comp.sources.unix submissions >ahead of time, and help give each package the workout it deserves? Say >so. Follow up to this message and make a commitment. I think that it's a darn good idea, and volunteer to help in any way that I can. What the heck, they always say that we run machines here at Purdue harder than anywhere on the planet... might as well keep true to the tradition! Count me in, Rich.. -- Gary A. Irick, Purdue University | "You can log out any time you like, INTERNET: irick@en.ecn.purdue.edu | But you can never leave!" UUCP: ...!ucbvax!pur-ee!irick | (apologies to The Eagles)
shurr@cbnews.att.com (Larry A. Shurr) (12/05/90)
In article <rodgers.660002277@clausius.mmwb.ucsf.edu>, rodgers@clausius.mmwb.ucsf.edu writes: } In <18766@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: } } }In article <10770:Nov3009:18:4790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: } }}You want comp.sources.unix to produce software faster? You want to } }}contribute some effort? Stop whining and start beta testing! } }This is a fantastic idea. } }I think a better idea would be a list of volunteers whom Rick distributes } }a list of packages amongst. } This is definitely worth pursuing... Agreed. Not only that, but I can volunteer as beta tester whereas I have to pass on the idea of me being moderator (I don't own the resources and I can't volunteer a client's resources in order to become moderator). If we can make this idea fly, I wish also to be a beta tester. regards, Larry -- Larry A. Shurr (cbnmva!las@att.ATT.COM or att!cbnmva!las) The end of the world has been delayed due to a shortage of trumpet players. (The above reflects my opinions, not those of AGS or AT&T, but you knew that.)
sean@utodaycom (Sean Fulton) (12/07/90)
In article <10770:Nov3009:18:4790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >You want comp.sources.unix to produce software faster? You want to >contribute some effort? Stop whining and start beta testing! > >I'd like to help. If Rich sends me each comp.sources.unix submission at >some stage of editing, I'll do my best to look at and test at least half >the packages in each volume. I'll tell Rich what I think about each >package, and I'll follow any guidelines he sets on things to look for. >I'll tell him if I ever find I no longer have the time or resources to >keep up with his schedule. > I'd like to help as well. I'm not sure if I've the experience needed to do serious editing, but I'd sure be into some beta work. I do appreciate the work Rich is doing and for those who find his schedule too slow, find an alternate group. I really haven't followed this thread from the beginning, but I've seen the bashing of late and it's really too bad. It's too bad because I've learned an incredible amount from working with software from comp.sources.unix, all the while fairly safe in the understanding that the sources I was getting were clean and thoroughly-tested. Piss off a volunteer and you might well lose him. And that would indeed be sad. -- Sean Fulton sean@utoday.com UNIX Today! (516) 562-5430 /* The opinions expressed above are not those of my employer */