On April 14, 2004 03:12 am, Anne Wilson wrote: > On Wednesday 14 April 2004 08:21, RichardA wrote: <snip> > > > No one expects Mandrake to actually communicate to their customers, > > even before a major restructure of the mirrors, but it seems they all > > went home for Easter withour fixing it. So much for Mandrake's > > 'enterprise' ambitions. > > An unfair and unjustified comment. Try reading the explanation on the > Club pages. The situation only developed as people were going home for > the holidays. Warly tried to contact the various mirror owners, but > they are totally independent of Mandrake, and most of them were > unavailable. Oddly enough, they like holidays, too. There is no way > that Mandrake employees can guarantee how long it will take mirror > owners to sort out this problem. Let's just hope that not too many of > them are taking an extended break. > Actually, Anne, Richard's comment is fair and justified. As is your response. One point I'd like to make is that the problem developed the monday prior to the Easter weekend and one of the reasons it occurred was communication with the mirror admins or the apparent lack of it.
What could have happened was that Mandrake (generic :-) ) could have done some testing of fixes over the weekend, announced that, and then they'd be in a position to have the fixes up and running by yesterday. Not all mirrors fixed to be sure, but working on it. That said, and I'm one of the very frustrated ones, there are things to be learned here. First off, never, ever do a major change the weekend before, during or after a major global long weekend. It's an invitation to disaster. And when you invite disaster it usually walks on in. I've learned this through painful personal experience. Second communicate major changes of things like mirror structures to all user groups. Before doing it. Communicate status of the changes, success, failure, partial success/failure. There is absolutely no reason not to and every reason to. A discussion on the cooker lists is not notification, btw. If you want to play in enterprise space then do things the way enterprises want it done. Third, test your changes. Retest. Break them. Figure out what can go wrong. Have a plan in place if and when it does go wrong. This wasn't done, as near as I can tell. At least there's no evidence anywhere that any testing was done. Fourth. Have a rollback/commit plan in place. Just in case. I did project management on this sort of thing for years before deciding that I much more enjoyed working with the equipment itself than planning around it. Over the years IT has developed some pretty well known rules around this kind of major change from hard experience in what can, and will, go wrong. There are very good reasons for the four points I mentioned above. There is a fifth. Fifth. Remember Murphy's Law. :-) I hope this is a learning experience for Mandrake and Warly as much as it is a frustrating and, quite truthfully, anger causing experience for us. That said, with the exception of one very important update, the rollout of 10CE has been a fairly painless experience for all concerned if traffic on this list is any indication. It's been polished, works and most of the rough edges taken off. What's surprising is how few messages have appeared saying that this release broke something compared to past releases. MDK 10 is a high quality bit of software, make no mistake about that. It's even better when we consider that 10CE is a public beta. In fact, it's gorgeous. :-) It's sad that this mess, perhaps not entirely preventable, may cause it a black eye. And this comes from poor planning on Warly's part. ttfn John
____________________________________________________ Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Join the Club : http://www.mandrakeclub.com ____________________________________________________
