I started responing to the comments in the other thread, but when my response got longer than the original post I decided to just create a new post.
Where to start? I think the first place is the Beta status of the FTFs – technically they are Betas which is why they contain Beta strings and appear in the Beta patches section, not the public patches section. They are considered Beta for the reasons in my next paragraph.
How much testing goes into an FTF? Historically it’s been very limited. I assume lots of you know about the engineering process but for those that don’t let me tell you what happens (at least in GW at Novell). When we ship a product we ‘branch’ the code. That is to say we create a new project in our code control system. One branch will become the new product in development and the other branch is for the SP to the product we just shipped. The only code changes going into the SP branch are fixes to issues that customers report – none of the code for new features in a future version go into the SP branch.
Often these changes are single line, or even single character changes and, therefore, are considered relatively low risk. I should say this is not always the case – don’t want to deceive you.
So, back to the testing question – the changes are sanity checked, the developer tests the change, the NTS employee (me) tests the change and often the reporting customer tests the change. If all goes well then the change is committed to the code contol system. So, the fix is tested, but we typically do not perform a full top down regression test. Time between FTF updates does not permit this. The other thing that I need to say is that FTFs are interchangable – the backend is just a set of NLMs/RPMs that you can swap out at will – if the FTF doesn’t work, just swap it out. I have never seen corruption issues caused by FTFs in my 7+ years on GW, if that allays anyone’s fears.
Periodically we will release a build of the SP branch as FTFs. In the past we had released just the files that changed, a-la NetWare, but that got way too complicated to test and be sure that something else wasn’t broken by the build mismatches. We, therefore, decided to release each component as a set even if some files hadn’t changed. More recently we decided to release all components simultaneously, so that issues around shared files didn’t crop up (GWENNx in particular).
Next I need to address the supportability of these patches. I can only talk for GW, and maybe Ron wants to pipe up for ZEN policy, but the GW team will NEVER refuse you support for a system running FTFs. I have worked in both of Novell’s GW support centers and this is the case in both – if a GW engineer tells you different then point them in my direction. On the other hand, we also don’t really expect customers to go rolling out FTF code enterprise wide, just because it’s available – we expect some personal responsibility on the part of our customers, whether the rollout is an FTF or a fully fledged support pack. My personal recommendation is very much ‘if it ain’t broke, don’t fix it’ – ie, if you aren’t suffering with one of the problems fixed in the FTF then don’t install it.
Lastly, time between FTF releases and full patch releases. We normally have a general idea when we are targetting an SP release for, and it’s normally timed to coincide with the Consolidated Support Pack release. This means that there are many months between SPs and we know that in advance – that’s why we release the FTFs – to provide relief in the short term. OK, off home now – sleep well 🙂