From: utzoo!decvax!harpo!npois!cbosgd!mark Newsgroups: net.news.b Title: Re: Suggested protocol for forwarding news fixes/improvements Article-I.D.: cbosgd.2425 Posted: Wed Jun 30 23:23:17 1982 Received: Thu Jul 1 06:38:45 1982 References: ittvax.373 I think Alan has made some excellent suggestions. I agree with all of them. I'd also like to make a couple of comments. There is no question that the current system of an update coming out randomly is a pain for everyone who maintains news on his system. A better way needs to be worked out. The current flurry of updates (2.7, 2.8, 2.9) really shows up the problem, even though 2.7 was the release and 2.[89] were fixes to serious bugs in 2.7. Probably a schedule for updates needs to be announced, in some way. An update can be planned, and it should be announced roughly a month or more in advance, so sites can plan to install it. These updates probably should come no more frequently than every 2 months. There should be a group of "test sites" to which new releases are sent for testing before they go out to everybody. Hopefully they would represent all the operating systems and hardware. The sites that have been doing most of the testing all seem to be vaxen running 4.1BSD. We also need test sites which (1) run USG UNIX, (2) are on the ARPANET, (3) run vanilla V7, (4) are pdp-11's, (5) are other things besides vaxen. Also, it is becoming clear that there are MANY sites running very old versions of news. These tend to cluster in certain parts of the network, for example, UCSD, BTL IH, Tektronix, and the NC Triangle were blatantly missing from the responses to my recent attempt to build a map. (So is Silicon Valley, because of reply problems due to arpanet addresses. Some of the others may have been reply problems too, but I can't tell.) These sites probably either (1) don't have the time/energy to update to a newer news, or (2) have significant local mods that they don't have the manpower to re-integrate into each release. We need to do something to make it easier for these sites to upgrade. In a network environment, you can't take the whole network down at once to change protocols, even if you control every site (which nobody does). Making a change to a new protocol is very hard, so changes have to be done in an upward compatible manner. If sites run 2 year old versions of news, it's hard to phase out some code that's in there for upward compatibility. With this in mind, I'd like to encourage sites with local mods to forward them to the maintainers. If the job of integrating them into the master copy is made easy, chances are very good that they will be bought back. (If the change is not an improvement for everybody, it can probably be ifdeffed.) We also might want to think about using netnews to automatically update and install itself. Obviously this not a well thought out issue and has lots of problems, but by posting to certain newsgroups (net.adm.all, presumably) it would be possible to have software (such as, but not restricted to, netnews) automatically updated. This service could be used for other things - the obvious immediate application is to keep the network map up to date. Also, a shell script or program to take an update and apply it (doing the local configuration, maybe using diff3, recompiling, and installing) would be a useful addition to news. Tools for the maintainer need some attention. Finally, there is the A vs B vs notesfiles issue. I think most of the people who have seen notesfiles think it has a wonderful user interface. What is not year clear is what happens with notesfiles in a big network. I propose a large scale test of notesfiles by having several volunteer sites form into a subnet of USENET, using notesfiles, with at least 2 gateways to the B news part of the net. Remember, there is nobody being paid ONE RED CENT to support USENET. Nobody at Duke, UNC, Berkeley, Bell Labs, or Illinois is being pressured by anyone to drop everything else and support news. All these people have some other thing they are (supposed to be) spending their time on, and support their software only as a labor of love. Much of what gets done is done because ONE OF YOU does it and sends the improvement to the central source. So next time you want to complain that you don't like feature X, or ran across bug Y, or want whistle Z, instead of flaming about it, get off your duff and fix it! This is a network of, by, and for the USERS. That's you! Mark