Kevin Kofler composed on 2015-08-03 13:05 (UTC+0200):
[re:
https://bugzilla.redhat.com/show_bug.cgi?id=1249280 ]
Kevin Kofler <kevin.kofler(a)chello.at> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DOWNSTREAM
Status|UNCONFIRMED |RESOLVED
--- Comment #19 from Kevin Kofler <kevin.kofler(a)chello.at> ---
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/