On Sat, 2014-01-25 at 15:04 -0500, Colin Walters wrote: > Hi Simo, > > On Sat, 2014-01-25 at 14:55 -0500, Simo Sorce wrote: > > > The reason is simple: lot's of software *changes* data as part of its > > normal functioning, including and often in rollback-incompatible ways. > > I wrote and maintain a system that has been doing continuous deployment > of GNOME. It's been running for over a year, and is nearing it's > 10000th build. > > I have "rolled" back many times - both on the server side, and on the > client side. Here's one I *just did* a few minutes ago because vala git > master broke the build of gnome-calculator: > > https://git.gnome.org/browse/gnome-continuous/commit/?id=32a52e53100e92aad5d2dfae969be82227322f49 > > That's me telling the system "please stop building git master, and > freeze to this specific commit". All clients get that change when they > upgrade - OSTree cares not at all for version numbers. > > The vala maintainers continue to work out the issue in git master, and I > continue to ship a working system. Double win. > > Now it's true, programs in GNOME do sometimes make the type of data > format transition you're talking about. Evolution has done it at least > twice. > > But you know what? My real world experience has been that having the > ability to roll back has *far* *far* *far* outweighed the downsides when > applications do format transitions. It's comparatively rare. > > Far more people are bit by things like hardware-specific issues where > gnome-shell fails to render on this particular card - and rollback works > beautifully for that. I never said it won't work in absolute, it probably will work ok in many cases, just to cause incredible issues in others. It is a fine tool in the hands of an expert that knows how to check whether reverting to a snapshot is safe. It is not going to be a good solution for non-expert users though *unless* you provide system APIs that *all* applications use to signal when they are doing irreversible changes so that the user can be warned about potential data loss right when he asks the system to revert a snapshot. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
