[PROTEL EDA USERS]: Service Patches (ex Re: Special Solder Paste)

["Geoff Harland" <gharland@ingenico.com.au>]

<snip>
> 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.
<snip>
> 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.
>
> Abdulrahman Lomax

The concept of frequent releases of patches has a lot to be said for it. In
its ideal form (from the user perspective), users would have the ability to
download either a relatively small "incremental" type file (containing just
the most recent change(s) to the software), or a larger "differential" type
file (containing all of the changes to the software since the initial
release of that version of Protel). Users who always downloaded patches upon
their release would be able to download the smaller former file on each such
occasion, whereas those who have not done so would still be able to acquire
*all* of the changes (to date) by downloading the larger latter file
instead.

However, creating two sets of files for downloading (along with
comprehensively testing these, etc) would involve more work on Protel's
behalf, and the size of an "incremental" file would not necessarily be
significantly smaller than that of a "differential" file (but it *might* be
possible to achieve this). For all that though, I would not complain about
Protel releasing (just) "differential" type files (Service Packs) on a more
frequent basis, even though each Service Pack is normally larger in size
than any of its predecessors.

And I fully concur that mission-critical bugs should be rectified at the
earliest opportunity. Ideally, a patch/Service Pack should be released ASAP
after this has been reported, and unless other fixes can be incorporated at
the same time *without* delaying the release of this, then the sole purpose
of this patch/Service Pack should be to rectify that particular bug.

It would be good for patches/Service Packs to be released on a more frequent
basis to also rectify bugs of a less serious nature. But in this regard, I
would regard the rapid release of patches/Service Packs to rectify
mission-critical bugs as being more critical, and as such, a case could be
made for accepting a larger time interval between the reporting of a bug of
a less serious nature and the release of a patch/Service Pack containing
code to rectify it. (In the interim, corresponents to this forum can often
provide advice on workarounds or procedures to follow, to avoid or overcome
any such bug concerned.)

Regards,
Geoff Harland.
-----------------------------
E-Mail Disclaimer
The Information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
e-mail by anyone else is unauthorised. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. Any opinions or advice contained in this e-mail are
confidential and not for public display.