JOHNSON@NORTHEASTERN.EDU (I am only an egg.) (01/09/90)
>Assuming we distribute full source for each new >version, how do you propose to distribute fixes, >for example the fix recently posted by Lenny >Glassman for the OPEN/MAIL problem? (Thanks, >Lenny.) Should we issue a new source version every >time a 2 line patch is added? If we do, then >everyone will have a different version of the >source, ie some people will have V5.9, some V5.9A, >etc. If someone fixes a problem, and postes a >patch, it will be more difficult to distribute to >the world, because there isn't any STANDARD source >against which to apply it. I never said it was perfect. > >I agree that it would be a good to simplify the >process of updating to a new version of NEWS. My >recent posting of the SLP patchs as command files >was an attempt to simplify the process somewhat. >Would you be satisfied if you loaded some BASE >source, and then typed a couple of commands which >would automatically update the BASE source to the >current patch level? >-- >Bob Sloane, University of Kansas Computer Center, The simpler the betterer. I think one of my bigger objections is that most patching requires human intervention in some way or other. People are prone to screw-ups, some of us more than others. Plus the fact that sometimes various networks chuck in their two cents worth. I still remember a set of patches from a v5.8 that got folded to 80 characters and messed up the patching that way. I suppose a two line patch doesn't bother me much. At least I can see the whole thing without putting on my glasses. I would probably have a good chance of understanding something that small also and therefore wouldn't be as terrified as I usually am when running a DEC auto-patch (they change the binaries without tell you what they're changing). What really bothers me is when the patches get really big I guess. Or maybe also when there are a lot of them that bothers me too. After 21 years in the computer business I guess my paranoia is showing. I'll take any suggestions to make life simpler and safer for everyone. If a couple of typed command lines would update me from a base version them I'm all for it. Chris J. Northeastern U.
tp@mccall.uucp (01/19/90)
In article <ANU-NEWS%90010815084129@NDSUVM1.BITNET>, JOHNSON@NORTHEASTERN.EDU (I am only an egg.) writes: > The simpler the betterer. I think one of my bigger objections is > that most patching requires human intervention in some way or other. I beg to differ. I just got the VMS port of Larry Wall's patch utility (out of vmsnet.sources). I've been a fan of this utility for a long time, as I used to work on unix systems. It has always worked just about flawlessly. The VMS version seems just as solid (with the recently posted patch by Karsten Nyblad). I really gave it a work out. I didn't have the 5.9 sources, just 5.9a and 5.9b, which I produced by laboriously applying the 5.9b diffs to 5.9a and ignoring the parts that were already done. Since I still had the 5.9b diffs, I ran them against the 5.9b sources and let it reverse all the patches. Now I have a 5.9 baseline source to apply updates to. Then I ran the 5.9c diffs. Everything worked without a hitch! Suggestion: if you copy all the patches into one file, you can do the whole patch operation with one command, and you are sure of not missing any. > People are prone to screw-ups, some of us more than others. Plus the > fact that sometimes various networks chuck in their two cents worth. I > still remember a set of patches from a v5.8 that got folded to 80 > characters and messed up the patching that way. Patches distributed as VMS_SHARE's are supposed to be immune to all but the worst network munging. Nothing is perfect however. I assume you are on the mailing list rather than the newsgroup. I'm surprised if the munged patches actually checksummed ok, though. > I'll take any suggestions to make life simpler and safer for > everyone. If a couple of typed command lines would update me from a > base version them I'm all for it. OK, a couple of suggestions. The distribution of rn and b news software on unix seems to work quite well. There are a few things they do that I think work better than the way we are doing ANU NEWS. 1) Define a file to hold the patch level. For instance, create a file newsversion.h and have it contain only the news version, including patch level. This can then be checked by the Prereq: feature of patch to ensure that the patch is being applied to the appropriate version and patch level of the source (this file would always be patched first, so if there is a problem, you can stop before making any changes. (This version should be what is reported by the VERSION control message, and all other places the version is displayed.) 2) Distribute each patch relative to the previous patch, rather than a base level. This would allow one to receive already patched sources rather than having to get a base level and apply patches (for people just getting the software). Also, you wouldn't have to keep 2 copies of it around (base level and current level). 3) Have someone (in this case, obviously Geoff) in charge of distributing "official" patches. Whenever anyone sends out a patch, Geoff decides whether it is a good patch, and if so, distributes it with an official patch level (thus updating newsversion.h or whatever to the new patch level). Others who send out patches should be encouraged to update the patch level to something out of the normal sequence, for instance (note the X): #define NEWS_VERSION "VMS News - V5.9, patch level 6X" That way, no official patch will apply to that version, preventing unofficial patches from creeping into the code and messing up later patches. People applying unofficial patches MUST keep the official patch level source around (or do what I always did, keep the unofficial patch and use patch to remove it before applying the official patch, works just fine). 4) Have someone set up a mail server to supply the patches (the way Larry Wall does for rn, each patch contains instructions on how to get patches from his server). Anyone running PMDF can set up a mailserv to do this. You could have several (wouldn't want to be retrieving all these from Australia to the US!). 5) Distribute the patches as one patch file per directory (i.e. one for source, one for documentation, etc.). These are by far the easiest to apply. You don't really lose anything, as it is easier to fix problems by looking at the reject file than the patches anyway. 6) Distribute patch with NEWS so that everyone will have it to apply patches with. Again, they only have to get it once, and then the patches to news will also include patches to patch (if any) to keep it up to date. That way you know that the version of patch being used is the last one you sent out, and you can test the patch process before shipping the patch. 7) Only post new base levels when the amount of changes in a patch is so big that it is just as easy, or when the accumulated number of patches is unwieldy. People can always get a current patch level version from an archive. There is no reason for archives to maintain base versions, so they would presumably always have all patches installed. 8) I don't think any major changes to the build procedure are needed, as it works quite well. -- Terry Poot (800)255-2762, in Kansas (913)776-4041 The McCall Pattern Company, 615 McCall Rd., Manhattan, KS 66502, USA UUCP: rutgers!ksuvax1!mccall!tp Internet: tp%mccall@ksuvax1.cis.ksu.edu