Bob,
I came to the same conclusion. My gut says that the parser should only be
changed to fix reported bugs, which would require a Bird, in my opinion, or to
undergo a revision to match a new IBIS spec version. I would still opt for a
bird in the latter case, just to keep the formality there, a Big Bird, if you
will, to deal with a big revision. The detail for such a bird would be
minimal-- change parser to match spec-- end of bird.
For enhancements, I still think a bird is appropriate, but would not be required
for a standalone sign checker, or one that checked for vcc relativity per
Arpad's comment. A bird could be used then to cause the new utility to be
merged into the parser after it is proven good.
Will
Hey, Ibis guys!
I have been reading the accumulated mail from the past couple of days and see a
thread about whether or not to change the parser for the current sign problem
without a full blown bird. After thinking about it, it would seem a fairly
large
departure from "policy" to do that. But since I agree with Kellee that
_somethin g
is needed here, how about a stand alone utility to check this until we can fully
hash out a bird? ( Hatch out a bird? ) Seems it should not be too mch harder to
write this than to write the changes into the parser ( He says! ). Just a
thought ... I defer to the group to determine how good a thought it is.
Thanks,
______________________________________________ ____________________
| | Seeking to return to | / __________________O
| Bob Ward | the North Country, MN, | / /|________________
| bward@neosoft.com | WI, ND, SD, or MT. Also | / /_/________________O
| 713.568.4122 | considering Mtn. West. | /_____________________
|___________________|_________________________| |_____________________O
Received on Mon Mar 21 11:57:12 1994
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT