rob@pbhyf.PacBell.COM (Rob Bernardo) (08/20/88)
In article <6563@uwmcsd1.UUCP> jgd@csd1.milw.wisc.edu (John G Dobnick) writes:
+Lots of silence since the "tester's" mailing list was formed, then all of a
+sudden, I see this... [I am *not* picking on Mr. Klann -- I merely see his
+article as a "red flag"]
+
+From article <258@heurikon.UUCP>, by davek@heurikon.UUCP (David Klann):
+> [mentions some "design" changes "made" by Rob Bernardo]
+
+A question or two, if you please. I thought all you "testers" went off to the
+"back room" to *test*! Instead, it looks like you are doing *design* work!
+"...BCC change proposed...", "...suggestion for dealing with outgoing mail
+storage...", "...final decision on these *design changes* [emphasis mine] ...".
+
+This is beginning to sound like a "Hack Attack".
+(1) So, what is changing about Elm?
+(2) Can the rest of us Elm users have a say in what's going on?
+
+I suspect that there are* one or two people out here that may have a useful
+suggestion or two.
+
+Or am I being overly paranoid and misinterpreting reality here?
John,
Let me answer your questions since I am the person who "made" the "design"
changes. If I had indeed *made* design changes to Elm, I think you'd
expectedly have your feathers ruffled. That being the appearance of
things from postings here, I'd like to explain what has really happened.
Let's define some terms. In my participation in the testing group
I've made a distinction between coding bug fixes and design changes,
my *private* terms, which you may or may not use in the same sense.
If a fix changes code but does not change the author's intent - i.e.
he made a coding mistake - that's a coding bug fix.
If a fix changes code and also does not go along with the author's intended
algorhythm for handling an issue (i.e. the general requirements are
remain intact - getting the issue handled) - that's a design change.
There were two design changes I proposed to the elm testers. I also
provided the context diffs for implementing the change. My provision
of the context diffs does not oblige any tester to apply them, nor
does it oblige them to be applied by the "keeper of the source code".
What I did was to argue about the design change, wait for some input
from the other testers, and then provide the necessary context diffs.
I realize now from your posting that there are other people "seriously"
interested in elm who participate in this news group who aren't testers.
So from now on, if I should again come up with a proposed design change,
I shall post the issue to the net rather than mail it to the testers,
in order to get input.
The input I've asked for, btw, was not only "Do you think this is a good
idea?" but also "Was there a method to the madness in the apparently
faulted design?"
In my next two postings I will present the two design changes I proposed.
--
Rob Bernardo, Pacific Bell UNIX Small Bus. Systems Development & Maintenance
Email: ...![backbone]!pacbell!rob OR rob@PacBell.COM
Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, California