paf@uts.amdahl.com (Paul A. Fronberg) (05/18/89)
Since sending a mild flame concerning patch levels, I have received two
mail messages besides seeing one reply on the net.
One person from sun said that they were up to 14. mail.
One person said they were up to 12. mail.
One person posted that they were up to 13. posted.
I think the statistics are intersting. By the way, what is the real patch
level for patch. Please post as I don't want my mail box to explode.
My second point about posting something periodically or with the official
patches applied was inspired by the above suspicion. Also:
1. patch may not be sufficiently up to rev to handle patch file. I've
run into this problem already. What happens if patch is missing or
you are missing a level or two to it.
2. I believe that the total size of the patches to news now exceed the
size of news originally posted. This is probably true also for pearl
(at least first release) and also for rn. These are the extreme cases,
of course, but with critical software such as news or patch, don't we
want to encourage people to use the most up-to-date and bug-free code
as possible.
3. Where do you get some of the patches and distinguish between offical
patches and ad hoc ones? Some are only available via ARPANET. How
many times do we see "please send me patch #X for program Y". And
how many times have we suddenly seen patch #4 and are missing #2 and
#3. I don't know what the present status of the moderated source
groups are and what the official patch policies are. I see on archive
sites the moderated issued patches are included, but I don't know about
the ones from comp.sources.bugs or other groups (haven't looked
recently).
4. A long time problem has been with various levels of news on the net.
I remember that at one time there were nodes with 2.10.0, 2.10.1,
2.10.2, 2.10.3, beta 2.11 and released 2.11, not to mention all patch
levels in between on the net. The fact that it works at all may
be a major miracle. There appears to be considerable inertia in going
to a new release unless there are compelling reasons.
5. The chances of a patch being missed, lost, or corrupted is going to
increase as the number of patches increase. If you miss one, you
may not realize it for quite some time. Another suggestion is to
include the current patch level with the periodic index postings
for comp.sources and comp.sources.misc.
6. How many patches are going to go into a program. I have patches 40 and
beyond for rn (at least one version). At what point do we draw the line
and say there is a new releaase or do we go on to patch #127.
7. The readership of USENET is very transient. New readers are constantly
appearing. New nodes are constantly being added. Not only are they
going to be missing important net routines posted long ago, but
the intermideate patches will be missing as well. Without shar, or
uudecode/encode, or patch, they will be limited in regards to use of
USENET.
If we can post the maps (4-7 megabytes) once a month (for good reasons),
it seems to me that for 1% more (once a year posting) we can ensure that
everyone at least has access to the fixed, current versions for certain
programs. Note, I am not proposing something be reposted just because of
one or two patches, but for certain netwide critical packages a periodic
posting might be in order. Also when the patch number gets to be 8, 14
or 41, an offical posting might be made to bring the package up to a known
stable release.
Perhaps some sort of "kit" with the commonly requested programs could
be send out once every few months? 1 megabyte or so a year would probably be
sufficient. My canidates would be news, patch, uudecode/encode, arc (or
equivilant), binhex, shar. In short the programs necessary to access and
extract news programs/articles.
I don't know, it's just a few ideas for consideration. This article is getting
longer than I expected and I apologize for stepping on toes, rambling, and
breathing :-)rsalz@bbn.com (Rich Salz) (05/18/89)
In <3eCX02wo28gL01@amdahl.uts.amdahl.com> paf@uts.amdahl.com (Paul A. Fronberg) raises a number of interesting questions... I can only answer a couple of them: > 3. Where do you get some of the patches and distinguish between offical > patches and ad hoc ones? Ones that come from the author are the official patches. This is most easy to determine for stuff that comes through moderated source groups. In particular, whenever I get mailed patches I always forward them to the author. When something has no author (e.g., indent) or the author has seemed to lose interest or left (I can't think of an example off-hand, but I know it's happened), I try to make sure one person becomes the "recognized authority" on the program. Sometimes it's hard. Sometimes it means you wait a LONG time for "official" patches. > 5. The chances of a patch being missed, lost, or corrupted is going to > increase as the number of patches increase. If you miss one, you > may not realize it for quite some time. Another suggestion is to > include the current patch level with the periodic index postings > for comp.sources and comp.sources.misc. You have to read comp.sources.bugs. There's no two ways about it. The issue/volume structure works for lots of things, but is bad for handling source/patch references. When reading index lists, you have to be REAL CAREFUL about reading everything, looking for patches. Putting an annotation in the lists that "has since been patched XX times" is a good idea. > 6. How many patches are going to go into a program. I have patches 40 and > beyond for rn (at least one version). At what point do we draw the line > and say there is a new releaase or do we go on to patch #127. This is the easiest one to answer :-) "we" do nothing about it. The author of the program gets to draw the line. Yes, it is a pain sometimes to be at perl2.37 as opposed to perl3. >Perhaps some sort of "kit" with the commonly requested programs could >be send out once every few months? 1 megabyte or so a year would probably be >sufficient. My canidates would be news, patch, uudecode/encode, arc (or >equivilant), binhex, shar. In short the programs necessary to access and >extract news programs/articles. Interesting idea. Lots of people are against it. The information REALLY doesn't change all that much, and sites that are connected don't need it that badly (as opposed to the maps, say). Getting "news" software is easy: UUCP it from the person giving you your feed. Then, you can slowly bootstrap up to the latest revisions by going to pay places like UUNET or free places like MCDCHG. >I don't know, it's just a few ideas for consideration. This article is getting >longer than I expected and I apologize for stepping on toes ... Not at all; it's starting to be a real interesting discussion. Patches have long been problematic, mostly for mod.sources- comp.sources.unix postings. Some sites (such as the archives I maintain on UUNET) quietly put the patch files into the original posting directory, but this loses badly for those with strong senses of history and/or those who archive by issue/volume number (e.g., Purdue). You need a way for the random downloader to get the original posting and all the patches. The information provided with patches often is the only documentation of new features -- read through the 17 news patches and see that there's several config.sh options that are not documented anywhere else. (Rick and I talked about updating the install docs, but -- foolishly -- decided to wait for C or 3.0 news. Real soon now...:-) [Just taking a potshot, guys; don't flame me.] I'm working on providing an EXHAUSTIVE index for c.s.u, which includes forward references to patches, but it's a lot of work (and I don't have a BBN charge number for it :-). I think that patches somehow have to be worked into the current groups -- a new unmoderated "patch" group will cause more problems than it solves. If you have ideas, post them. For the time being, read comp.sources.bugs. /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
hans@nlgvax.UUCP (Hans Zuidam) (05/19/89)
In article <1730@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes: >In <3eCX02wo28gL01@amdahl.uts.amdahl.com> paf@uts.amdahl.com >(Paul A. Fronberg) raises a number of interesting questions... I can >only answer a couple of them: >>Perhaps some sort of "kit" with the commonly requested programs could >>be send out once every few months? 1 megabyte or so a year would probably be >>sufficient. My canidates would be news, patch, uudecode/encode, arc (or >>equivilant), binhex, shar. In short the programs necessary to access and >>extract news programs/articles. >Interesting idea. Lots of people are against it. The information REALLY >doesn't change all that much, and sites that are connected don't need it >that badly (as opposed to the maps, say). Getting "news" software is >easy: UUCP it from the person giving you your feed. Then, you can slowly >bootstrap up to the latest revisions by going to pay places like UUNET >or free places like MCDCHG. Some sort of "kit" would be *really* usefull. It would allow a new site to be up and running with the correct software in no time. However, posting such a kit every x months would be a gross waste of bandwidth assuming that most sites are running the correct software. When I was a (sort of) system manager at another site a couple of years ago it was a hell of a problem just to get started. I did not know if I had the correct software, saw people talking about patches I did not have, didn't know if I needed them and so on. When you start with a Usenet connection you generally do not even know what you *do* need. If you help a new site to get online you have to dig software from all corners of your filesystems ;-) and forget half. This takes a lot of time for both parties involved. A solution would be to make such a kit available on magnetic media (say tapes or floppies) at 'major' backbones. A new site could then send a SASE and a fee for handling costs and get it. Another (additional) sollution is to have the kit available at conferences, say Usenix, Eunet and the national or local ones. Hans -- Hans Zuidam E-Mail: hans@pcg.philips.nl Philips Telecommunications and Data Systems, Tel: +31 40 892288 Project Centre Geldrop, Building XR Willem Alexanderlaan 7B, 5664 AN Geldrop The Netherlands
earle@mahendo.Jpl.Nasa.Gov (Greg Earle) (05/24/89)
In article <3eCX02wo28gL01@amdahl.uts.amdahl.com> paf@uts.amdahl.com (Paul A. Fronberg) writes: >Since sending a mild flame concerning patch levels, I have received two >mail messages besides seeing one reply on the net. > >One person from sun said that they were up to 14. mail. >One person said they were up to 12. mail. >One person posted that they were up to 13. posted. > >I think the statistics are intersting. By the way, what is the real patch >level for patch. Please post as I don't want my mail box to explode. mahendo:2:18 % ftp jpl-devvax.jpl.nasa.gov Connected to jpl-devvax.jpl.nasa.gov 220 devvax FTP server (Version 4.162 Tue Nov 22 13:22:36 PST 1988) ready. Name (jpl-devvax:earle): anonymous Password (jpl-devvax:anonymous): 331 Guest login ok, send ident as password. 230 Guest login ok, access restrictions apply. ftp> cd pub 250 CWD command successful. ftp> ls -FCt 200 PORT command successful. 150 Opening data connection for /bin/ls (ascii mode) (0 bytes). rrn/ makeindex* tmp/ patch/ perl.2.0/ dist.2.0/ perl.3.0-alpha/ index patch.2.0/ avl.tar.Z read.1 4.3_networking_code/ x11r2_stuff/ bed.tar warp.7.0/ x10.4_stuff/ inbox/ cdiff.1.1/ rcs.tar.Z 226 Transfer complete. 215 bytes received in 0.43 seconds (0.48 Kbytes/s) ftp> ls "-FCt patch" 200 PORT command successful. 150 Opening data connection for /bin/ls (ascii mode) (0 bytes). 226 Transfer complete. ftp> ls "-FCt patch.2.0" 200 PORT command successful. 150 Opening data connection for /bin/ls (ascii mode) (0 bytes). README kits@12/ patches/ 226 Transfer complete. 27 bytes received in 0.20 seconds (0.13 Kbytes/s) ftp> ls "-FCt patch.2.0/patches" 200 PORT command successful. 150 Opening data connection for /bin/ls (ascii mode) (0 bytes). patch12 patch10 patch9 patch6 patch5 patch2 patch11 patch7 patch8 patch4 patch3 patch1 226 Transfer complete. 89 bytes received in 0.52 seconds (0.17 Kbytes/s) ftp> close 221 Goodbye. ftp> quit mahendo:2:19 % mconnect jpl-devvax connecting to host jpl-devvax (128.149.1.143), port 25 connection open 220 devvax.Jpl.Nasa.Gov Sendmail 5.51/4.7 ready at Tue, 23 May 89 21:24:34 PDT VRFY lwall 250 Larry Wall <"| /u/sfoc/lwall/bin/mailagent /u/sfoc/lwall lwall Larry >>/u/sf oc/lwall/.maillog 2>&1"> QUIT 221 devvax.Jpl.Nasa.Gov closing connection mahendo:2:20 % patch -v $Header: patch.c,v 2.0.1.6 88/06/22 20:46:39 lwall Locked $ Patch level: 12 mahendo:2:21 % ------------------------------------------------------------------------------ `patch' hasn't had a new patch in almost a year. I hope that you can see that it is clearly at patch level 12, since this is Larry's machine. I hope this ends this discussion once and for all. - Greg Earle Sun Microsystems, Inc. JPL on-site Software Support earle@Sun.COM earle@mahendo.JPL.NASA.GOV (Guest)