For those of you who have been following along at home (or trying to implement Quickr) you will have noticed that the hotfixes are coming fast and furious. Along the way that has led to some negative comments around the forums and blogosphere, for example this forum
Four hot fixes in quick order following the release of 8.0.0.2 for Domino also does not give me great confidence in the product.
or a comment to this posting on the Quickr Blog
This is becoming disconcerting… talk about a product released a bit too early…
Well I disagree with both comments, and others that I have heard regarding the frequency of hotfixes, I say keep them coming. What is happening here is not that the software was released too soon or without testing, rather that IBM has made it easier for all of us, by making these fixes available without first having to find the problem, open a PMR, and then have support provide the hotfix, which all this time was there and coded and could have avoided the problem in the first place. The Notes from Lotus Support blog covered this topic in September, detailing the creation of Fix Central and the effort to make more hotfixes available this way (you can also note in the comments to the post that entitlement to support is not even a requirement in all cases to be able to download a hotfix). Another point to consider is that while there have now been six hotfixes for Quickr 8.0.0.2 (curiously numbered 1,2,3,4,6,7, did anyone ever see 5?) they have each been cumulative, so if you ignored them all and then ran in to a situation where you needed a fix, you got them all. Lets compare this what is going on in other Lotus Products, if you take a look at the Notes/Domino Fix list you can see that the Fixpacks only contain a limited number of fixes, my understanding is the Fixpacks are designed to fix the SPR that are generating the most support calls, not a bad strategy, but look at the numbers of fixes, even if you are running 7.0.2 with a fixpack there are still any number of 1000 known issues you can run in to (enter Murphy). In additions the releases of versions or Fixpacks rarely if ever coincide with my organizations maintenance schedule, but if the hotfixes were distributed regularly via Fix Central I could at least apply fixes for the majority of known issues each time I have a window to perform maintenance. There is obviously a little more complexity to doing this for a Domino server with all the various server components as opposed to Quickr but I am sure they could be worked out, for example limiting hotfix builds to only specific versions and fixpack levels. Today you can download hotfixes for Quickr, Quickplace (see Technote 4017549), and Connections on Fix Central. There are options to choose Domino and Sametime in the product list, for Domino the Fixpacks are posted, and the Sametime 8.0 Hotfix is available. I will not complain about too many hotfixes for Quickr, my complaint is some of the other products need to do as good of a job at getting the fixes available so quickly and easily. Quickr 8.0.0.2 Release History Quickr 8.0.0.2 – October 29, 2007 Quickr 8.0.0.2 HF1 – October 31, 2007 Quickr 8.0.0.2 HF2 – November 21, 2007 Quickr 8.0.0.2 HF3 – December 9, 2007 Quickr 8.0.0.2 HF4 – December 10, 2007 Quickr 8.0.0.2 HF6 – December 19, 2007 Quickr 8.0.0.2 HF7 – December 20, 2007
Don’t take this the wrong way, Mitch, but I think one of the reasons why there might be a perception of too many fixes is because each one generates a flurry of “there’s a hotfix out” blog posts from you, Stuart and Chris. And that’s just the ones I know about.
If you guys (and the rest of the Quickr user world) will quit treating patches as an event, that’ll probably calm the storm down a bit.
Otherwise, yeah, I agree 100% that the more the better. People need to start thinking differently about what a “version” of software really means. Can you even tell when Google or Facebook or Skype or AIM release a new patch? Of course not, and they’re probably delivering hotfixes on a daily basis.
This isn’t your father’s development cycle.
Good points Mitch. However, my concern is that the patches are badly documented and poorly packaged.
It isn’t clear how important the hot fixes are, nor how essential it is to get them deployed. Regarding the packaging, I honestly don’t think that IBM should be asking the customers to be manually copying fixes around for a product like Quickr. It increases the likelyhood of installs becoming out of step and more problems arising as a result.
I recently took part in some user testing for Fix central where a number of these issues came up, so hopefully there will be improvements along the way.
@Nathan, fair point, though at the time Mitch and I publicised the first HotFix, we didn’t have any idea that there would be so many in such a short time.
@Nathan, If we didn’t post about the hotfixes then nobody would know they’re out there. I haven’t seen anything come through my Quickr support RSS feeds related to the hotfix releases.
Have you seen the process for patching a Quickr server? It’s not your father’s self-extracting executable!
Now we’re just having fun seeing who can notify the community first – because IBM isn’t doing it…
@Nathan, I see your point, but again it all depends on how you look at it, I see the release activity as a big positive, so why not publicize them, and as Chris points out in his comment, there is no feed or other official announcements from IBM regarding the fixes.
@Stuart, 100% agree regarding the packaging of the fixes and the lack of an installer, which I have mentioned once or twice. I think this is a work in progress with the move to the Fix Central strategy and I would expect to see the process improve over time.
Perhaps the term Hotfix is part of the problem, maybe there needs to be a better term to describe them which will have a more positive connation.