Recovery ideas ranged from being able to put an update onto a user’s machine whether he wanted it or not to snapshot/rollback support and having some kind of a “safe mode” where it would give you a kdrive-based VESA X server and tools to fix your system. I’m not sure what we would do if we managed to break one of those tools (or the “safe-mode” X server), though.
Hopefully, we will have a procedure in place in a little while which tells us how to handle such an emergency when it happens and we will be deploying safeguards to prevent it from happening again while not ending up paralysing us and making us unable to deploy updates to
$distro-updates as this is something we need to be able to.
While this post is fairly critical of the current set of policies and procedures, I have tried hard to avoid pointing fingers at anybody in particular. I would much rather have us have a positive and constructive discussion about how to avoid similar problems in the future than a discussion on who is to blame. The points and views in this post is also those of my own and not any kind of official communication from Canonical or Ubuntu.
Thank you Tollef for keeping everyone updated and for being open.
I really like the fact that communication in the Ubuntu community is (relatively) open and transparant.
Wiesbaden Sprint news on the fridge
forum thread in the Ubuntu Cafe called “How could an update break X?”
related blog entries :