Re: [PROTEL EDA USERS]: Special Solder Paste

[Abd ul-Rahman Lomax <marjan@vom.com>]

<x-flowed>
At 11:12 PM 10/19/00 +1000, Ian Wilson wrote:

>The first gotcha is that the auto-router will rip up additional copper 
>portions of the complex pad in some circumstances - this is a bug and I 
>would like it fixed soon!

It's not only a bug, it is a mission-critical bug, by which I mean that a 
bad or even useless board can be produced because of it with no warning to 
the user. A bad board can cost more than the purchase price of the 
software, and perhaps I should mention that it can cost more than a license 
for a competing product!

There should be a list of all mission-critical bugs such that users can 
readily become familiar with it. I'd suggest a checklist, in fact, with 
documentation of workarounds and ways to verify that a bug has not affected 
a file.

Mission-critical bugs are clearly the most serious type of bug and there 
should be little excuse for one remaining beyond the next service pack; 
further, Protel has indicated that it will issue service packs more 
frequently rather than waiting to accumulate many changes. Protel has taken 
some flack from people who claim that the fact of the issuance of five 
service packs to Protel 99 is evidence that the software is very buggy. 
Please, Protel, don't buy it! I'd recommend, in fact, very frequent service 
patches, a patch being defined as a piece of code which fixes one 
particular problem, or perhaps a few problems, whereas a service pack 
includes many fixes which have been accumulated over a period of time.

I've heard comments that frequent service patches cause support problems 
because there can be many, many versions out there depending on which 
patches have been applied. This problem can be solved by not providing 
support, or at least not guaranteed support, for anything other than the 
most recent version of a tool (i.e. the most recent version of 3, 98, or 
99). Support should not have to deal with questions regarding bugs which 
have already been fixed. Each patch would check for the currency of the 
files (as of the previous patch). At the same time, a file would be 
maintained that would contain all cumulative revisions so that an 
alternative would always be a fresh installation followed by the cumulative 
service pack.

Instead of calling service packs by number, they would be dated, and there 
would, at any time, be only one available service pack, the current one. 
There would also be a list of patches with their dates, and a user could 
check the current patch status of his or her software and download only the 
later patches, which would need to be applied in sequence.

It is also possible to have software update itself, or at least inform the 
user of a current uninstalled patch, requesting permission to download and 
install it. But that requires, of course, a live internet connection. Some 
users won't have that.

I do recognise that the issuance of frequent patches can cause problems 
with bug fix interactions, particularly where there might be two different 
programmers working on bugs affecting, or requiring changes in, the same 
routines. However, each individual patch would itself be thoroughly tested 
before release, or if a set of patches are released at once, that set would 
have been tested as a package, so interaction problems would generally be 
caught internally or by Beta volunteers.

If we had such a system, we might see a mission-critical bug report and 
then a fix within a few days.

marjan@vom.com
Abdulrahman Lomax
P.O. Box 690
El Verano, CA 95433



</x-flowed>