On Fri, 16 Jul 2004 14:34:35 -0400, Gene Heskett <gene.heskett@xxxxxxxxxxx> wrote: > >I'm sure there must be many people like me > >who would be willing to run test releases > >but who don't have a spare machine to devote to this purpose, > >or the time or inclination to re-install every 3 months. Logic fault.... if you aren't prepared to do a fresh install NIGHTLY becuase of a problem in a test release.. you aren't prepared to do testing. There is no shame in not being able to test. The only shame comes with people come into the testing situation expecting something other than reality. Running a test release is all about watching your computer meltdown and ooze out of the case. Having a degree in foresenic science to help figure out what when wrong by examining the puddle on the floor helps a lot. > If you want to make incremental test 1, test 2 etc releases in the > form of snapshot iso's, thats fine, but at the same time, we should > be able to use yum or one of the *-carpet things to bring our > existing test installs to be identical, over time so that at new > release date, our systems are equal, or not more than say 10 packages > out of date to the new release. The current method seems to invite > breakage of too many things all at once. Who said you can't use yum to do the upgrades... competent people are able to do this just fine assuming there are no packaging problems and are not trying to upgrade a configuration that can not be upgraded live. But there are certain facts that everyone who attempts to do this must face. 1) There are things you can not do properly while booted into the running system. The ramdisk based installer environment in acaconda is NEEDED for some upgrade situations because low level changes that can not be reconfigured while in the live system. ( lvm -> lvm2 migration is soooo much fun) As soon as someone very clever figures out a way to deal with those corner cases, I'm sure that person will earn themselves a nice fresh KK doughnut and a pat on the back. 2) when using ANY test releaese and upgrading it using ANY method..be it anaconda or live..do not expect it to actually work. Expect it to eat your system. Sort of the point about testing...being prepared for problems and knowing how to report them accurately so they can get fixed. If your expecting a running system after upgrading to or from a test release, you have misunderstood why test releases exist and what is expected from you as a tester. Do not pass go do not collect $200. 3) Updating from a test release to a final release is NEVER going to be suppoted. no matter if you use anaconda or yum. Changes such as package downgrades that can occur between the last test release isos to the new release can have unexpected problems. Remember its a TEST RELEASE, everything invovling a TEST release has to be considered UNTESTED, and you are running it to DO the TESTING. Which means upgrading from a TEST release has to be considered UNTESTED. Nothing, absolutely nothing regarding any action you do with a test release can be expected to work correctly. thats the WHOLE point of providing test releases... to make sure upgrading from a full release to full release gets sorted out. Feel free to prove me wrong, and come up with a clever package management system that understands the concept of 'downgrading' a package cleanly (and no... epoch doesn't count as a clean solution). -jef"Looking for the magical door to lead him to the land where packaging bugs don't happen and all upgrades go cleanly everytime"spaleta