From: Jesus Monroy Jr (jmonroy@netcom.com) Subject: [The Great Patch-kit Debate] Bugs, Annomolies, Patches, Hacks, Fixes, Rewrites & Experimental Newsgroups: comp.os.386bsd.development View this article only Date: 1993-04-08 03:26:12 PST /------------------------\ THE GREAT PATCH-KIT DEBATE \________________________/ Bugs, Anomalies, Patches, Hacks, Fixes, Rewrites & Experimental --------------------------------- I have not said anything about the patch-kit(s) in the past, as I am well aware of the problems involved. Before anything, I have to say with qualification I have respect for the valiant job that the patch-kit makers are doing. The experiences I will lend you, I hope may persuade you. I have broken the discussions into several pieces for easier digestion by all involved. My Experience With Patches -------------------------- Over two years ago, before I had ever heard about 386bsd, John Sokol, my former business partner, and I were well into our commercial project. The project involved the parallel port. John had made a device, total cost about $1.50, that attached to the port and allowed sound to pass through it, via the MS-DOS operating system. It was received well. We sold it for about $25.00 wholesale. We did well, except whenever we needed to make patches to the code.... The run-time binary was less than 3k. The micro-kernel for the playback routine was 15 lines of assembly. 27 other lines were involved with the segment and interrupt fixes. The fixes were done so that we could run on an IBM pc-xt. Inclusively speaking, we had what we thought was the best product for the market, bang per buck. How does all this relate to the source code? Many small bugs in the code altered the normal development in a consistent manner. An annoyance remaining, in the code, is not being able to interrupt the playback via the keyboard. I know it sounds like I am still straying, but please continue with me. At about the third month, John and I decided to take our code to some pc-game companies, but we knew we needed a smaller micro-kernel to really make a sale. Working independently and without much discussion, we arrived at separate solutions. Two months later, we made comparisons in great detail, my code proved to be better by only *1* clock tick. In the end, we lost the focus of our business deals and could not continue to make money. It was all trivial and pointless. John and I both realize this now. If we had only worked out a system for patches (or fixes), we could have saved valuable time, effort and sanity. John Sokol helped with the launch of version 0.0 of 386bsd. I know some of us miss him. Not related to our business directly, John filed for bankruptcy and divorce. He is now working in the super-micro-technology of tomorrow. The company he works for is making visible, to commercial entities, objects that may only be seen with electron microscopes. I am here with you. Proposed Ideas for the Patch-kits. ---------------------------------- I won't trivialize this with a discussion on philosophy of any sort. I will let you all work on any details that you see fit. These are only my ideas. First I will define some terms. 1) BUG - A known reoccurring problem with known conditions of frequency. 2) ANOMALY - A known problem of irregular frequency & with unknown solutions. 3) PATCH - Minimal code insertions, which differentiate it from the original code in an attempt to solve a known problem. 4) HACK - An attempt to solve an irritation. 5) FIX - The real solution to a known software or hardware bug, as defined by a known standard. 6) REWRITE - Trash the original version; REALLY fix the problem. 7) EXPERIMENTAL - A solution of dubious nature that attempts to go beyond the stable condition. 8) OPTIONAL - Going beyond the base installation package. (ie., X-11r5 windows, compressed file system) A BUG_LIST ---------- If it is a bug, then the "unoffical bug reporters" should add it to their list, with qualifications that pertain to lists. The same "unoffical bug reporters" should maintain a "fixed_bug_list" which describes the solution and how to find it. The solution should be sasink(sp?). example: use "neosoft"patch-kit 0.0.0; patch00012 _or_ use "nate's"patch-kit 0.2.0; patch01020 _or_ email julian@xyz.xyz.edu This may reduce sporadic solutions and maybe better ideas. ***********Do you have any yet?*************** Break up the solutions ---------------------- Next, break up the patch-kit as such: BUG_LIST \ [ 96 hour (every four days) updates BUG_FIX_LIST +------[ if not daily updates ANOMALIES / [ \ \+------------Note: Provide a mailing list of the reported anomalies to all interested developers. A different patch system ------------------------ The author of the code can (and must) make a differentiation about the type of code he is sending. Here are some more ideas for the patching system. PATCH-KIT - Released weekly without regard for consequence to the user. Mainly to speed the testing and coordination of the code development. The user applying this *must* be on a mailing list. He can not expect any help from anyone, except the author. HACK-KIT - The same as above. This is just different code. FIX-KIT - What the current patch-kit is doing. Namely deep tests to arrive at a reasonable solution. The procedures for testing should be published and included in the patch-kit. REWRITE - Completed FIX-KITs or a whole new implementation to be merge in with the upcoming *release*. OPTIONAL & EXPERIMENTAL - From the current stable platform, and any REWRITES that apply, for people that need to be far ahead of the current. This is done so as to have a medium in which to communicate. ********************************************************************* ** - ALL KITS SHOULD HAVE AN INTRINSIC CODING AND DATING SYSTEM. - ** ********************************************************************* LAST NOTE --------- You are invited to add or flame, to your hearts content, but do *NOT* e-mail me on this subject. As of now, I am working on the FDC driver, the QIC driver & QIC NEWS. I am helping the people in OS/2, LINUX and MACH with the QIC implementation. I have also had requests for help in writing ethernet implementations and help in debugging XFREE86 for the LINUX group. I will not reply to any mail on this debate. If you want a response from me *POST IT TO THE NET*. Thank your for your time. ___________________________________________________________________________ Jesus Monroy Jr jmonroy@netcom.com /386BSD/device-drivers /fd /qic /clock /documentation ___________________________________________________________________________ Message 2 in thread From: Chris G. Demetriou (cgd@erewhon.CS.Berkeley.EDU) Subject: Re: [The Great Patch-kit Debate] Bugs, Annomolies, Patches, Hacks, Fixes, Rewrites & Experimental Newsgroups: comp.os.386bsd.development View this article only Date: 1993-04-08 04:36:53 PST In article jmonroy@netcom.com (Jesus Monroy Jr) writes: > [ ... ] >PATCH-KIT - Released weekly without regard for consequence > [ ... ] >HACK-KIT - The same as above. This is just different code. > [ ... ] i think the thing to emphasize here is "Released weekly". as some of you are, i'm sure, aware, i'm one of the people involved in trying to get together an interim release. basically, the goal will be an initial source- and binary- release, to get everybody "in sync" with my environment. then, weekly, complete diffs from the previous week will be automatically (as in: with cron) posted to the net. subsequent "full releases" will happen, but, for a while, only the source release will be updated automatically. i think that *regularity* of releases of fixes and bug lists should be the "prime directive", if only because it lets people know what is going on. I think that this regularity is one major area in which linux currently has an advantage over 386bsd. chris whose come to love CVS... it makes it pretty easy to manage 5 or 7 hackers, beating on a 50+M source tree... -- Chris G. Demetriou cgd@cs.berkeley.edu "386bsd as depth first search: whenever you go to fix something you find that 3 more things are actually broken." -- Adam Glass Message 3 in thread From: Jesus Monroy Jr (jmonroy@netcom.com) Subject: Re: [The Great Patch-kit Debate] Bugs, Annomolies, Patches, Hacks, Fixes, Rewrites & Experimental Newsgroups: comp.os.386bsd.development View this article only Date: 1993-04-08 22:39:16 PST mail cgd@erewhon.CS.Berkeley.EDU re: Subject: Re: [The Great Patch-kit Debate] Bugs, Annomolies, Patches, Hacks, Fixes, Rewrites & Experimental >> In article jmonroy@netcom.com (Jesus Monroy Jr) writes: >> > [ ... ] >> > PATCH-KIT - Released weekly without regard for consequence >> > [ ... ] >> > HACK-KIT - The same as above. This is just different code. >> > [ ... ] >> >> i think the thing to emphasize here is "Released weekly". >> YES, definitely >> as some of you are, i'm sure, aware, i'm one of the people involved >> in trying to get together an interim release. >> Kinda. >> basically, the goal will be an initial source- and binary- release, >> to get everybody "in sync" with my environment. >> Yeek, Is that the bezerkely enviroment? ^ ^ < \_____/ >> then, weekly, >> complete diffs from the previous week will be automatically >> (as in: with cron) posted to the net. subsequent "full releases" >> will happen, but, for a while, only the source release >> will be updated automatically. >> Sound good!