Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!bbn.com!rsalz From: rsalz@bbn.com (Rich Salz) Newsgroups: comp.sources.d Subject: Re: regarding patch level of patch Message-ID: <1730@fig.bbn.com> Date: 18 May 89 13:40:37 GMT References: <3eCX02wo28gL01@amdahl.uts.amdahl.com> Organization: BBN Systems and Technologies Corporation Lines: 76 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.