Jeff Spaleta wrote: > On Mon, Feb 9, 2009 at 12:14 PM, Mark Haney <mhaney@xxxxxxxxxxxxxxxx> wrote: >> That said, rolling updates are the way to go. No need for continual >> upgrades to 'releases' just update to the latest version of a package >> and be done with it. I'm just not sure a 'major release' design is the >> way to go any longer. With internet access the way it is, why not just >> do rolling updates? > > Do you understand that there are some operations which can not be done > on the running system. The jump to kernel 2.6 and the migration to > using udev from the static device naming scheme are not the sort of > things that you could have been done easily with rolling updates. > These are examples of a class of low level technology changes which > make preupgrade and the installer imaging worthwhile compared to live > upgrades. That doesn't say live upgrades are impossible, but it may > require extra effort on your part to deal with low level changes that > you may not completely understand and that package management is not > designed to solve. Being a die hard gentoo user for the last 3+ years, I understand that certain operations can't be done on a running system. That is not my point. My point is that a large portion of the updates /can/ be done on a running system. How many times do these 'low level technology changes' actually happen compared to normal updates. > > Additionally rolling updates significantly complicate testing. Static > release points make it possible to carve out a set of priority test > cases as part of the pre-release process and focus on those senarios > to make sure they get the most testings. We do not have the resources > to test all possible upgrade scenarios that you could run into. Bugs > happen. Bugs will continue to happen. If we spread testing so thin > that we are trying to test every possible upgrade scenario..they will > all work equally poorly. What we can do is prioritize testing. Highest > priority is fresh installs...because ultimately that is the fall back. > Next highest priority is upgrades via media or preupgrade. Live > upgrades would be prioritized both of those given the manpower > available. Sure, I can understand that. The gentoo world does something very similar with it's 'profiles'. A set point of package versions and libraries it bases it's next 'version' on. It builds on that profile from then on. It's worked perfectly for me for years now. There's no reason you can't do the same with Fedora. Just make it clear not updating to that 'point' won't be supported. > > Once you come to terms with these last two paragraphs, you are free to > attempt to do rolling updates by switching your fedora-release package > (rawhide or the next Fedora release) with the knowledge that you may > run into some deep level incompatibility that the live/rolling > upgrades can not handle. > > -jef > I do rolling updates with an OS designed with that in mind. I don't do that with Fedora, primarily because I have production servers that need stable packages. The current design of Fedora doesn't handle rolling updates, so I play by the Fedora rules on those systems. I just fail to see why Fedora can't be handled the same way as Gentoo. It's all linux. They are all the same packages. I'm not advocating or demanding a change, just voicing my opinion on it. I'm not that kind of revolutionary, I just think rolling updates are the way to go. *puts up soapbox* -- Frustra laborant quotquot se calculationibus fatigant pro inventione quadraturae circuli Mark Haney Sr. Systems Administrator ERC Broadband (828) 350-2415 Call (866) ERC-7110 for after hours support -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
