Kevin Kofler composed on 2015-08-03 13:05 (UTC+0200): > https://bugs.kde.org/show_bug.cgi?id=350853 [re: https://bugzilla.redhat.com/show_bug.cgi?id=1249280 ] > Kevin Kofler <kevin.kofler@xxxxxxxxx> changed: > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |DOWNSTREAM > Status|UNCONFIRMED |RESOLVED > --- Comment #19 from Kevin Kofler <kevin.kofler@xxxxxxxxx> --- > I'm resolving this bug as DOWNSTREAM (missing package-level dependency). As I > wrote above, the KWin issues are unrelated and need a separate bug report. > By the way: >> Except for Knoppix, which I boot maybe 2-3 sessions per year, I don't download or >> boot from burned .iso images. I most often install to HD via HTTP started from Grub >> loading installation kernel and initrd, rarely from booting installation media, never >> via pxe, always manually, like a non-developer user might, not making use of >> installation scripting like Kickstart. > 1. Especially BECAUSE you have hardware that many developers don't have, you > should be more responsive to requests for testing. (But in this case, I happen Need doesn't automatically create supply. I can't create any more hours in a day any better than any FOSS project can fill a developer void. I do what I can, but within limits, of which some are necessarily arbitrary chosen. > to also have a Radeon 9200 SE and can and will test it myself. That doesn't My rv200 is a Radeon 7500, in a P4 machine. I also have other rv200s I can swap into other machines if and when necessary, and an rv250/m9, which is a FireGL (a virtual Radeon 9000), but it's in an Athlon machine (no sse2), resulting in https://bugs.kde.org/show_bug.cgi?id=346244 which I only just found out has ceased blocking running K5. > mean testing the live image on your machines wouldn't also be useful, because > your hardware is almost certainly not identical to mine. And by the way, the > Radeon 9200 SE is my primary machine, so it's not true all the devs use brand > new hardware. :-) Of course not all, but certainly dev use of newer machines is the more common situation. Not everyone is willing or able to fix rather than replace when hardware failure occurs or freespace is exhausted. > 2. The live image is the most effective way to test a known-good Fedora setup, > without affecting any of the installations present on the machine. Burn (or put > on a USB stick, if your machine supports booting from USB), boot and see what > happens. I didn't ask you to install from it, just to test ON the live image. Volunteers generally have a right to choose what they will do. I don't keep track of which of my machines are capable of booting from other than internal HD. Some don't boot from USB. Some have dead OM drives. Trying alternate booting on older machines often results in time-consuming and distracting forays into why booting only works from HD, or booting quits altogether. Hardware failure diagnosis gobbles time that might otherwise be spent on software testing too. > 3. Because of your unusual setup, it is important to know for debugging whether > this also happens on a known-good default setup. This is why I asked you to > test the live image. The why part is an understood given. Would better that anyone not reply at all rather than announce decline of a particular request? Usually when I report a bug I've already tried reproduction cross-distro, cross-release and/or cross-hardware, a usually suitable alternative to booting a live image only on one machine. As noted above, for the rv200 this is here blocked by an unrelated bug. > 4. A non-developer user should not, and hopefully will usually not, install > from netinstall with "minimal X". We recommend all our users to always install > from the live image. So you are in fact NOT testing what normal users will get. One of the touted features of FOSS is choice. Users aren't QA robots. Regressions amount to choices lost. Better that losses be googleable even when they can't or won't get fixed. > 5. If you report bugs from heavily-customized Fedora installations, please > indicate so from day 1. Not knowing this wasted a lot of our time debugging the > issue. Bug reporting takes copious time when taking the trouble to acquire a reliable reproduction scenario first. Here, exhaustion often sets in or bits of memory fail before clicking the submit button. When I know of a customization that could affect the scenario, I try to account for it when possible, but I'm human, not robot. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
