[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: terminology and the hierarchy of releases



Robert P. J. Day wrote:

On Mon, 9 Feb 2004, William Hooper wrote: ...

A better way to look at it:

What value would there be to using the FC1 base and updates repos on a
rawhide install?  I don't really think there is any because you want the
development packages to be installed, not the FC1 packages.


just to be pedantic, it's not a rawhide "install" you'd be looking at here; it's an *update* based on rawhide. the question was, if you were
looking at doing a massive update based on the rawhide repo, would
having the updates or testing repos in your yum.conf potentially cause
problems?


and, based on some of the previous postings, technically, that should
work, since upgrading based on rawhide is supposed to simulate upgrading
to the next release, which should work.

but, realistically, who knows?

rday



I have upgraded an all development system and also have a system that is an upgrade from FC1 with repositories for testing, updates and base. I don't see too much differences between the systems.


There is an item that gets hidden with an upgraded system and probably gets a lot of problems overlooked. This is for a default account and if things will be created from the default skel or not. Xmms is one item that had this problem on both of my systems. I believe creating and deleting user accounts would be a good practice to thoroughly check out programs for functionality. Having existing users and seeing what goes well and what fails is also a good idea, in my view.

After listening to some discussions about some programs never making it to development, but going straight into testing. (compilers, etc). I think that at least these repositories should be investigated to see the interaction if one was to compile software or things that bypass development.

About the factor of upgrading from test1, test2, test3 then to the release. I have a laptop with an Athlon processor. It is working fine through this method. It all depends upon your interest in the testing. Having different setups and situations is a positive move to test more possibilities and possible interactions in hardware/setups.

A valid test would be to try as many different options and schemes out and report the results.

The only pristine conditions That I could see is fedora 1 with no updates applied to test release or straight to the test release. I doubt that people will have either type of condition when upgrading from Fedora 1 to Fedora 2. You need the spectrum in between to really test out the quality of the next release.

Just my perception.

Jim




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]