Re: WARNING: Say "NO" to patched versions!

Daniel Wright (dw420@airmail.net) wrote: : : highest), and wanted a fix. It may be shortsighted to ignore the : possibility of introducing other bugs just to get a fix in for the : current problem, but this is the reality of how people see software. : They want it fixed and 90% of the time, if you give them a fix and they : test it to see whether or not the fix fixed the problem at hand, they'll : be happy, even though there may be unwanted (possibly worse) side Customers are *always* told that patches is the last resort, and it has *no* QA run on it. Interims run a subset of QA, which we think should catch any regressions, and of course the commercial release run the entire QA. Patches are very difficult to do and involves 'hunting' machines with exact OS, compiler release levels, source code level etc. Clearly, it is next to impossible to stock every conceivable platform with every level of OS or the cost of patch will escalate thru the roof. ( Customers are not charge for patches, right ? ) Having said that, customers still *demand* patches, and sometimes we shrug our shoulders and gave in to them. Trust me, we make every effort and try hard ( very ) to make customers happy. At times, even though there are workarounds in place, they still demand patches, and we still gave in - despite the fact that it makes no economical sense. And about QA - well, it is not very easy to run. A full set of QA take weeks and truly stress the various components. With each higher version, there are more features to QA on. Partial QA will take a few days to run, to say the least. I think it is not quite possible for every bug fixed to be subjected to full QA and issue a patch. At that rate, a person will probably fix at most 4-5 bugs per year - which is clearly not acceptable to customers, and of course informix cannot be hiring 1000 workers just to fix bugs to roll out interims and patches. Which is why you probably heard by now - bug fixes are rolled into an interim every month, and at least customer has a predictable schedule of when their bug might be fixed and rolled in. From what I know, from the time we identified a bug - and know a viable code fix - it takes about 1.5 months for it to roll out. But still many customers claim they cannot wait that long. It is a continuing struggle to make the best of resources, and pleasing customers. Usually, the latter wins ( in fact, I have never encountered a case where the manager says 'screw the customer, let them wait' ). : effects.If Informix (and other software vendors), were more : straightforward about fixing problems and offered upgrades at no (or : insignificant) cost when major problems were found, and additionally : informed everyone of the fact that the full QA process was not done on : 'patches', then noone would want a patch, unless they needed it NOW and : the next release was 2-3 months off (as they told us and our customer). I think that is not true. No matter how much we warn the customer, it is usually "I want it NOW". Upgrades - I do not know the fees so I cannot comment. We have customers asking for bug fixes going all the way back to version 4 and 6. As you probably know, these are no longer supported, according to the product live cycle. But nonetheless, most of the time, we end up bending backwards to satisfy the customer. The customers have to understand that if they all demand patches for every release, when a minor upgrade can easily solve their problem, support will end up losing focus and trying to please everybody. I do agree though - that if you hit a bug that is fixed on later release - you get the upgrade for free or at a huge discount - but then again, support does not set pricing policies. : I know nothing is perfect and software will always contain bugs, but we : as users and/or programmers must always continuously demand perfection, : and be satisfied with nothing less.In the case of our customer who has : accepted a patch, but will probably eventually upgrade once the newer : Informix release is certified by our own QA department for use with our : product, they were faced with the possibility of losing lots of money : while hundreds of users sat helplessly while the database was restored. : These users would not only be paid for the downtime, but would then be : paid time and a half (or whatever the union rate is) to complete the : work they should have been able to during their regular working hours, : but couldn't due to Informix bugs (which in their eyes is our fault). I think it is your right as a customer to demand what you have paid for - which is a product as bugless as possible, and if not - bugs that are not devastating enough to corrupt or destroy your business. I think the support is very mindful that no matter what policies we can come up with, there will be customers who say they cannot upgrade - due to OS release, their internal QA, etc. Which is why, so far as I have known, we have never turn down patches even tough the bug is not critical or show stopping. I have never worked in any other organisation that bend so far backward to satisfy the customers at such great expense to themselves, and perhaps this perception is not felt for all informix customers. E.g. after setting up the enviroment for patches, it is a matter of compilation and making sure compilation goes properly. Some of us end up doing it over the weekend using our own time on our own PC. We are not paid OT, heck, our managers/directors are not even aware, and why ? Because we understand that bugs does not inconvenience only DBAs', but 10s, hundreds or maybe thousands of users and weekends is the best time to roll in any changes. We are just doing the best we can with many customers demanding patches rather than wait. On a final note, support are always thinking of various ways to cut down this patch time, and improving the process. Trust me, support hate making patches too - it is time and resource consuming and distract us from a lot of urgent tasks. In the end, customers will just probably say 'hey, it is informix problem, they should fixed it, even if it means hiring more people and buying more machines'. I know, because I was once a customer too. Sorry that I rattle on and on .......