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

Re: Testing test releases: do not update

Gerry Tool wrote:

I heartily agree with this. The uncoordinated mixture of rawhide packages, fixed packages and original test release packages leaves a very ill defined state of a system on which to base bug reports. I have broken my Test 1 system by trying to keep up with rawhide and would need to backtrack to a fresh install and start all the upgrading over again to do anything useful for this testing phase. That is too much effort, particularly if I have to rinse and repeat again. The testing of RH8 and RH9 was much better coordinated, with most testers dealing only with released packages and packages explicitly claimed to fix particular bugs. I also think it is *very* important that testers be given a coherent set of guidelines as described above by Robert J. Day.

Feeling impotent to help because my test sytem is hopelessly borked by rawhide updates.

Gerry Tool

Since I was actually using development and reported a few bugs before the Fedora2 Test1 release, I can say that staying at the state that the original ISO was released as would have put the problems and distribution back a ways, without the additional updates applied to Fedora, after the initial installation.
Upgrading to the post-install rpms allowed for some of the known issues to be fixed that were fixed during the development tree.

Bugs that I found in development were with the lost and found entries on the KDE menu, xmms segfaulting and occasional problems trying to install ftp or http installations with anaconda.

With adding upgrades to the mix for FC2T1, I do see additional probelms with more breakage. (Kernel and a few other issues). Overall, I don't think that the added factors are distracting from the overall effort to mold FC2T1 into the FC2T2 phase.

Problems that I am currently seeing are alsa interferes with xmms. Alsa ramps up CPU usage, alsa is not compiled with alsa in, by default.

Other bugs that I see are with items such as configuration of modules for the new modprobe.conf setup seems to be pretty much of a do it yourself effort.

Another is that trying to select a file through the gedit file selector is pretty much limited to unhidden files and you cannot type in the desired file and have it selected. The file shows, but will not take.

Also, I noticed that my flatbed scanner works with the 2.4 kernel and with the current development programs. The scanner is not recognized with the 2.6 kernel.

Other than these issues and with a few added distractions, with default settings, I think the test phase is pretty decent. (Though frustrations with trying to do simple tasks, that used to just work may cause one to feel that the distro s heading the wrong direction.)

I do hope that phase 2 needs less updates and is less of a do it yourself effort though. Also, the idea of making a repository for errata updates seperate from development might be a less radical aproach to getting updates. If a fix is said to be fixed during the test phase, then throwing it in a dedicated repository sounds like a great idea.

Anyway, on with the testing and to report some needs attention items.


While you recently had your problems on the run, they've regrouped and
are making another attack.

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