Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!decwrl!netcomsv!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: [The Great Patch-kit Debate] Bugs, Annomolies, Patches, Hacks, Fixes, Rewrites & Experimental
Message-ID: <jmonroyC55tAy.462@netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Date: Thu, 8 Apr 1993 10:04:09 GMT
Lines: 199
/------------------------\
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
___________________________________________________________________________