I haven’t been writing a lot as I’ve been going crazy at work and nothing has jumped out at me as time sensitive. I’ve starting writing some “expert” blogs for AIIM on Enterprise Content Management, their label, so you can get a small fix over in the AIIM Community.
It is the summer and things are pretty slow going in the industry, but that doesn’t mean that I can’t build-up to a good rant. I was doing a little research in some release notes for Documentum the other day and something that annoyed me last Spring hit me full in the face.
The proliferation of patches. WOW! Let’s look at this for a minute.
In Theory…
I can’t tell you how many times I have installed a system, not just Documentum, and eventually come across a bug. Usually I have to open a ticket with the vendor, convince them that I’m doing things correctly, and then, if I’m lucky, I might get a bug fix.
Then there are those bugs that you don’t find until after damage has been done. At that point, you not only have to fix the problem, you have to repair the damage. That can be costly (though you do learn a lot about the inner workings of the system in question).
To solve this, a little over a year ago, EMC began releasing regular (1-2 months) patches for its active software. Excellent! If I’m installing a system I can add the latest patch. I can also review patch notes to see if there are any fixes that may be worth installing before the next Service Pack or Release.
As For Execution…
The biggest problem is the sheer number of patches. If a product is out for a year, you can expect 10-12 patches. That is 10-12 Release Notes and 10-12 packages. Let’s look at the previous version, Content Server 6.6, which triggered my effort.
I went to find the Release Notes because I was checking an environment certification and I didn’t have the notes already downloaded. There were 11 set of patches mixed in with the base product. Given that the Content Server includes the xPlore search engine and lots of different pieces of Documentation, there are 30+ files listed normally. There were also 50+ patch files!
After some time, I discovered that I could filter the patches out of the listing, speeding-up my Release Notes retrieval. The issue is that if I needed to download the latest patches, I would have been challenged.
The files are listed in patch order. There is a sort column that you like to think will list them in that order, but it doesn’t. As a result, determining which of the patch files are the latest version is challenging at best.
Keep in mind, this scenario is replicated across all products.
The Fix…?
To be honest, they have to keep all the patches up there for download. You never know when someone will need to match an exact environment and re-download a set of patches. That doesn’t mean that it can’t be easier.
Two things need to be done.
- EMC needs a way to clearly indicate the latest patch release for all software. As not all software gets a new patch with each release, this isn’t necessarily as easy as looking for patch “11” across all version 6.6 products. Maybe put all patches in Powerlink, leaving only the latest in the Download Center.
- Patches need to be better tagged/organized. They don’t sort in patch order and I can’t sort by date. As it stands, when I browse the Content Server products, I have to scan the entire list for every patch file of a given patch release.
Kudos to EMC for releasing these patches. I can’t find a reason to really argue against the process. They have already served me well, though due to the headache above, determining how to successfully patch the previous release of xCP in January was a nightmare.
Just PLEASE make the download decision process to be less cryptic.
Thank you.
Word of Pie 
Thanks for the post. Right on target.
The other question is can you really trust the documentation from EMC, whether it be for patches or for the base product? They need a patch process to be added for all the “bugs” that I find in the documentation. I have been burned far to many times with the following statement from EMC support… “That’s not a product bug that’s a documentation bug. Engineers say that it is designed to specification. You have to submit a feature request.” In case they don’t know it, customers plan and design solutions around the documentation they publish. It’s not just for helping us fall to sleep at night.
LikeLike
Documentation is actually a completely separate issue. The documentation should be “virtual documents” with section being updated and then having that section tagged for backward compatibility. Updates could then be published. Baseline release note, say for 6.6, should be updated to included bugs that have been identified and for which patches were released, a patch history.
To be honest, they need a good XML document solution, potentially based upon DITA.
LikeLike
AFAIK, our TechPubs do have an XML solution based on DITA 🙂
LikeLike
Then it should be used to its full advantage.
LikeLike
Actually, they should only include the latest patch I think, since it includes all those before. I know that some organisations only want the patch that affect them for some issue, but more often than not you apply the latest patch anyway for the “just in case” scenario.
Would cut a lot of the clutter 🙂
LikeLike
I can think of instances where you might want a past patch, mostly tied to replicating environments. For instance, if I want to create an environment in my lab that mirrors a specific client’s environment, I need to be able to download and apply the exact patches that they have deployed. We just need those older patches tucked out of the way.
LikeLike
If I understand it correctly and from what I’ve been told, there are no more Service Packs. If so, this is a big problem with the patches. Service Packs also included new features, patches do not. Also, the point of the patching system was so bugs could be addressed quicker, though P01 for 6.7 took a long time to be released. I’m not sure but it may have taken as long as it would ordinarily take for an SP1 to be released. One thing though, the patches don’t all need to be installed. They are usually, at least from I’ve seen, cumulative.
LikeLike
Mark, you are correct on most points. I’ve heard that there may still be Service Packs, and the first 6.7 patch came out much faster than a Service Pack, though longer than their patch plan. I like the system to some degree, but the download site is a mess.
LikeLike
Hi Laurence,
Interesting post. I’m not that experienced with Documentum but I have clearly been suffering of similar issues in the past with other software…
12 patch releases a year looks a good pace to me from a maintenance point of view, however from what I read, I understand EMC support the product whatever the combination of installed/not installed patches is? Or is it a sequence and each new patch includes the previous one(like a service-pack traditionally does) or may be the Support T&Cs implies it is installed to be supported?
No need to say that 12 independent patches leads to a very high number of combinations… that can only lead to nightmares for software vendors (… and system integrators) if they want to provide bullet-proof QA for all of them!
(and forget about implementing continuous testing / integration)
Cheers,
LikeLike
Roland, they are cumulative. Really, the issue is the sheer chaos in the download center once the patch count starts to climb. I like fixes coming out. I also like being able to readily find any patch level or the latest patch without having to think real hard.
LikeLike
Hey Pie,
I am a developer with Documentum.
I hear you and would make sure you feedback reaches the right ears. I’ll keep you posted.
LikeLike