hoyt@polyslo.CalPoly.EDU (Sir Hoyt) (08/10/89)
In article <1989Aug9.164003.20669@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >of prerequisite patches that is in *every* patch. (I agree this would >get unwieldy if there were 57 of them, but there won't be.) Are you sure? software of the nature tends to live a very long time. New hardware comes out and presto problems. >[stuff about date-base patches deleted] What I do not like about date-based patches: People talk about patches in news groups. And if some says 'X program at <some date>-patch does this....", I find this harder to cope with then 'X program at patch level N ...'. Because level N says there have been N patches to the program, whereas <some date> says the program was last patched on <some date>. This is different. Information has been lost with the date-based patch scheme. You can no longer tell how many patches there have been by simply looking at the version and patch level. Now you say 'look at the patch file, all previous patches are listed there'. Well what about a binary that spits out the version and patch level? Is it suppose to list every patch? or just the latest? Also if you see the patch of <some date> appears, you can't tell if you are missing any patches by looking at the patch-date itself. Because a date does not hold that information. Whereas a patch level number does. One must also remember why patch levels exist, and that is to make *OUR* lives easier. They are there so that we can easily see if program X has become out of date. Nothing more. And if the quit making our lives easier they are worthless. Patch level numbers instantly tell you if you have missed any patches, patch dates do not. >more problems than it solves. So far I see little evidence for this. >Convincing us is going to require good arguments, not endless repetition >of poor ones. Evidence? Well I know ( from read news.software.b ) that C news has patches. But I do not know how many. Because people talk about <some date>-patch, not patch number N. To me this is a problem, I have to spend more of my time trying to figure out how many patches there are. I for one have enough to do already. -- John H. Pochmara A career is great, UUCP: {csun,voder,trwind}!polyslo!hoyt But you can't run your Internet: hoyt@polyslo.CalPoly.EDU fingers through its hair -Graffiti 4/13/83
jad@dayton.UUCP (J. Deters) (08/17/89)
In article <1989Aug9.164003.20669@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >more problems than it solves. So far I see little evidence for this. >Convincing us is going to require good arguments, not endless repetition >of poor ones. A correctly used patch system will need numbers. Not want. Need. If you want to know where your program is in relation to the patch you have, a system of Release.Revision.PatchLevel is almost mandatory. Dates hide the history of the code without substantial digging into documentation. I'd hate to have to go through the posting to find the README file that has a list of release dates and changes to find that I missed a release somewhere, when it is intuitively obvious that 5.4.1 is 4 releases higher than my current 1.3.6. :-) This also tells me that many things such as file layouts, etc. have probably changed since I put my code in, while 5.5 probably will drop right on top of 5.4.6 without my worrying about it. You may think that the general public knows enough about your code to know that you put in a widget-seeking algorithm that restructures your save file when you went from 5/21/86-3 to 7/01/86, but it's not obvious by looking at those dates. 3.7.6 to 4.0 kind of stands out as a warning. Set it up so that if a Release comes out, you know to dump any source code you have and re-install the new source. If a Revision comes out, you know that you can apply it to ANY previously applied Revisions to this release. Cumulative patches in the Revisions make life easier for the installers. You don't have to waste hundreds, if not thousands of net.dollars posting messages like "Can somebody send me foobar 12/15/88? I have foobar 12/01/88 but I just received foobar patch 12/15/88 patch 1" Instead, you *know* that foobar 3.2 can be applied to foobar 3.0. If a PatchLevel comes out, you must apply it to the appropriate Release and Revision, but you may or may not need previous PatchLevels depending on your philosophy of distribution. I personally prefer cumulative patches, such that 3.2.1 is not a pre-requisite to installing 3.2.2, but for net distribution I will concede that diff's to previous PatchLevels are smaller, and therefore more acceptable. You then automatically know that you will need to find 3.2.1 and 3.2.2 before you can apply 3.2.3 to your copy of 3.2. You also know that if you can't get 3.2, you may as well hit the 'n' key. Dates are worthless unless you like to issue full releases every time somebody thinks adding a couple of widget keys would be neat-o. If you miss just one non-cumulative patch, you're hosed. (You're hosed in the PatchLevel situation described above, too, but at least you know it. :-) Having cumulative Revisions keeps the full-source releases down. Date-based patch identification prevents using an intelligent system. And adding a revision into the middle of the ID such as mm/dd/yy-rev-patch is just another way of restating the above while still hiding the history of the code. I realize that this may require the distributor and/or author of changes to code to actually keep track of what's been done. At least everyone who receives the code won't have to have perfect memories. -j -- J. Deters - jad@dayton.DHDSC.MN.ORG john@jaded.DHDSC.MN.ORG
henry@utzoo.uucp (Henry Spencer) (08/18/89)
In article <6717@dayton.UUCP> jad@dayton.UUCP (J. Deters) writes: >A correctly used patch system will need numbers. Not want. Need. >If you want to know where your program is in relation to the patch you have, >a system of Release.Revision.PatchLevel is almost mandatory... Assuming that you are talking about one of those pieces of, uh, software that is constantly changing, with bales of new features and swarms of new bugs regularly showing up. My opinion of such mushware is very low indeed; Geoff's opinion is unprintable. Particularly for the news transport subsystem, where specs are quite solidly fixed by backward-compatibility constraints, we see no fundamental reason why a well-written piece of software cannot stabilize fairly quickly and then remain essentially unaltered unless and until it is replaced by a complete rewrite on radically different principles. This is the model we are working towards: software, not mushware. We may not achieve it, but we are determined to try. (Indeed, we are not interested in trying the alternative.) -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
rick@uunet.UU.NET (Rick Adams) (08/18/89)
In article <1989Aug17.171000.23302@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > Particularly for the news transport subsystem, where specs are quite solidly > fixed by backward-compatibility constraints, we see no fundamental reason No matter what one thinks of Cnews, it is is not backward-compatible. Cnews is another transport system (just like notes is). it may be better or worse, but it clearly paid no attention to backwards compatibility.
scs@itivax.iti.org (Steve Simmons) (08/18/89)
henry@utzoo.uucp (Henry Spencer) writes: >In article <6717@dayton.UUCP> jad@dayton.UUCP (J. Deters) writes: >>A correctly used patch system will need numbers. Not want. Need. >>If you want to know where your program is in relation to the patch you have, >>a system of Release.Revision.PatchLevel is almost mandatory... >Assuming that you are talking about one of those pieces of, uh, software >that is constantly changing, with bales of new features and swarms of >new bugs regularly showing up. My opinion of such mushware is very low >indeed; Geoff's opinion is unprintable. >. . . we see no fundamental reason >why a well-written piece of software cannot stabilize fairly quickly and >then remain essentially unaltered unless and until it is replaced by a >complete rewrite on radically different principles. This is the model >we are working towards: software, not mushware. We may not achieve it, >but we are determined to try. (Indeed, we are not interested in trying >the alternative.) Sorry for the long requote, but given the response I'm about to make it seemed only fair. Henry, your response in no way addresses the request. Deters (and I, in seperate mail) have both stated that a patch numbering system in less ambiguous than your date-oriented system. While I salute your efforts towards quality software (and would even say you're succeeding) your responses to this issue have (a) not addressed it and (b) verged on . . . ah . . . emotional. I realize you are not trying to be insulting, but a response laden with terms like "mushware" and "unprintable" would lead the casual reader to assume you are applying those terms to the feature (patch numbering) being requested. The main virtues of patch numbering are twofold: First, they give an absolutely unambiguous way of telling you how many patches must be obtained. By contract, patch dating can lead one into a cycle of not being quite sure one has the previous patches (one gets the june 17 patch only to discover you now need the june 2 patch. get that, only to find you now need the april 1 patch. i realize you don't put out a lot of patches. your posting/patching frequency is irrelevant to the quality of number vs. date as a methodology). Second, patch numbers are easier to remember. One simple number, rather than a date. -- Steve Simmons scs@vax3.iti.org Industrial Technology Institute Ann Arbor, MI. "Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
henry@utzoo.uucp (Henry Spencer) (08/20/89)
In article <2876@itivax.iti.org> scs@itivax.iti.org (Steve Simmons) writes: >... i realize you don't put out a lot >of patches. your posting/patching frequency is irrelevant to the quality >of number vs. date as a methodology)... Ah, but this is exactly my point: it's not. The difference between the various bookkeeping systems becomes significant only for large numbers of patches. We hope to solve the how-to-track-lots-of-patches problem by avoiding it entirely. If there are only a handful of patches, it just doesn't matter that much. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
geoff@desint.UUCP (Geoff Kuenning) (08/20/89)
In article <1989Aug19.215016.23031@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > Ah, but this is exactly my point: it's not. The difference between the > various bookkeeping systems becomes significant only for large numbers > of patches. We hope to solve the how-to-track-lots-of-patches problem > by avoiding it entirely. If there are only a handful of patches, it just > doesn't matter that much. Henry, you don't exactly strike me as wet behind the ears. I'm pretty sure that you were on the net before I was, and I'm also pretty sure I've seen you write about your memories of computing in the 60's. Even if my memory is wrong, it's rather clear from years of watching your postings that you're no fool. While I am less familiar with Geoff's work, I think I can safely assume that he, too, reaches far beyond mere competence in his chosen field. Why, then, is it that you take such a wet-behind-the-ears attitude towards the bugs in and the longevity of your own software? Surely you've heard the saying, "there is no such thing as a bug-free program?" Surely you've dealt with other people's software for long enough to realize that even widely-respected software by widely-respected programmers has lots of bugs that require corrections? Computers have existed for almost 45 years now, and certain things have been learned during that time. One of the lessons is that maintenance is an unfortunate reality, and smart people plan for many years of maintenance. C news is certain to exist for many years. Neither Henry nor Geoff is even vaguely stupid (hell, Geoff even spells his name correctly :-). So why not study the maintenance lessons that others have struggled so painfully to learn? Five years from now, whether the total number of C news patches is 3 or 45, people will have a much easier time keeping track of the patches if they are numbered and handled professionally. Climb down off your arrogant pedestals, Henry and Geoff. The reality is that you are not the only superb programmers in the world. If you learn from the lessons of other superb programmers, you will look less foolish in a few years. Check out Knuth's article in the July '89 SP&E on bugs in TeX (I'm presuming you accept my premise that Knuth is no idiot, either). And face the truth: well-designed maintenance is superior to poorly-designed maintenance, regardless of how much is required. Why, when you have put so much effort into good design of your software, do you think it is an advantage to be deliberately sloppy about maintenance? Shoddiness is shoddiness, regardless of where it is found. -- Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff
flee@psuvax1.cs.psu.edu (Felix Lee) (08/21/89)
I don't understand the fuss. All I need to know is whether my installation of GammaSoftware is current or not. Release dates and numbers are equal in that respect. If you're out of date you say, "I have 14 July 1789, bring me up to date". The only problem is deciding whether to apply N updates or fetch the latest release. Which is only an issue if you're egregiously out of date. And this decision could be made by your friendly softwaredistributor or archiveserver. Or am I missing the point? -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!flee
henry@utzoo.uucp (Henry Spencer) (08/22/89)
In article <173@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >And face the truth: well-designed maintenance is superior to >poorly-designed maintenance, regardless of how much is required. Why, >when you have put so much effort into good design of your software, do >you think it is an advantage to be deliberately sloppy about maintenance? The key disagreement here is that we do not consider our scheme poorly- designed or sloppy. Different, yes. And we admit that we consider it experimental. For various reasons, however, we like it and want to give it a serious trial. To reiterate: We are interested in hearing about any serious non-obvious problems with our scheme. We are not interested in hearing repeatedly about the obvious ones; we feel, at this time, that it has enough advantages to counterbalance them. We are not interested in hearing how silly we are not to have thought of the obvious problems; we *have* thought of them. We are not interested in reading long explanations of how we're being silly, or of how it's sinful and unprofessional to do things in unusual ways; we disagree. At the very least, if people *must* repeat all the arguments we've already seen 57 times, after having thought of them ourselves beforehand anyway, we urge that it be done by private mail and *not* by further postings to this newsgroup. It's really getting boring and tedious, guys. If you must inflict it on us, at least have the decency not to inflict it on others. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (08/24/89)
In article <1989Aug19.215016.23031@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >If there are only a handful of patches, it just >doesn't matter that much. Then why don't you accept the fact that the overwhelming majority of us want numbered patches and switch? Or, run both systems in parallel. Both rcs and sccs can stamp files with revision numbers and dates. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA CTIX-USERS has moved to: ctix-users[-request]@cs.AthabascaU.CA