evan@telly.on.ca (Evan Leibovitch) (05/12/89)
In article <918@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >>I've become really disgusted with the amount of patching that goes >>into some of the posted software. I would much rather wait for a >>tested release than be the unintentional beta tester that many people >>have become. >>E.g., I would have brought up elm to replace mailx but there was >>patch 1, patch 2, ..., patch 7! All in the space of a few weeks. It >>might have been the case that elm would have worked fine for me but >>this was *not* encouraging! To which csu@alembic.acs.com (Dave Mack) replies: >This is an unrealistic point of view. It is pretty much impossible >for a developer to test every aspect of even a medium-sized system >on all the different machines with all the ever-so-slightly-different >operating systems that you find on the net. >In the case of Elm 2.2, it was usable as it was distributed. The >patches have been either to accomodate the peculiarities of a >particular machine or operating system, or to fix relatively minor >bugs in obscure and little-used parts of the system. >I agree that there should be a minimal level of debugged functionality >in a package when it gets distributed, but you picked a remarkably >bad example to make your point with. I don't think so. To me, the issue is not whether patches are necessary, but the frequency with which they're issued. Most of the elm patches were marked medium to low priority. Why could they not be lumped together in a single patch, rather than a few little ones? Why could one not set milestones, say every quarter, at which time all non-crucial fixes done since the last patch are sent out as a single patch? Of course, patches which fix fatal errors get sent right away. But that was not the case with elm. Instead, we have bunches of "I missed patch N - who has it?" postings, and patches posted to the bugs group, rather than the sources group, so that some automatic archiving sites miss them. If the patches were non-critical, why could they not have survived waiting in line in the sources group? Look, this isn't meant as a knock on those who have given the community such a wonderful program. But for a volunteer effort, I suggest that it is *less* work to send out fewer patches at regular intervals, than to send out each fix as soon as it's written. Fewer revision levels, fewer pre-requisite files to keep track of, easier for both the developer and the end-user to maintain. -- Evan Leibovitch, SA, Telly Online, located in beautiful Brampton, Ontario evan@telly.on.ca / {uunet!attcan,utzoo}!telly!evan / (416) 452-0504 Scientists have proven conclusively: Research causes cancer in lab animals
" Maynard) (05/15/89)
In article <1989May12.154952.3818@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >To me, the issue is not whether patches are necessary, but the frequency >with which they're issued. Most of the elm patches were marked medium to >low priority. Why could they not be lumped together in a single patch, >rather than a few little ones? Why could one not set milestones, say every >quarter, at which time all non-crucial fixes done since the last patch >are sent out as a single patch? >Of course, patches which fix fatal errors get sent right away. But that >was not the case with elm. Fatal errors for who? Just one machine? Or everyone? All of the patches so far, except 3 and 5, fix bugs specific to one environment. (Possibly patch 6 doesn't, but I haven't gotten that one yet.) I don't accept that that kind of thing should have to wait even as long as a month to get distributed, and that's too often according to your statement above. If the stuff won't run on my system, I want the fix now if it's known, not two months from now. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------- {killer,bellcore}!texbell! | "Less great!" "Tastes filling!"