On Aug 21, 2014, at 2:20 PM, Lars Seipel <lars.seipel(a)gmail.com> wrote:
On Thu, Aug 21, 2014 at 01:13:07PM -0600, Chris Murphy wrote:
> If it can be fixed in Fedora, but we need more time or whatever to get it fixed, then
I think we should block. But we're not allowed to block on anything vbox specific no
matter what the problem or solution is.
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=1103496
The problem with that bug doesn't seem to be a lack of time but more a
lack of interest. If no one cares enough about the bug to go after it,
it won't get magically fixed by just waiting for it, except maybe by
coincidence. Blocking the release on it might coerce some contributor
into fixing it but that's not a viable long-term strategy for a project.
And never blocking is also not a viable long-terms strategy. The blocking dance is a skill
to equalize the fact some problems are important enough even if it's not affecting so
many people that it immediately gets fixed. This happens all the time and if it didn't
we'd have a much lower quality release.
To support something you really need people interested in working on it.
In all the time that bug has been open apparently no one thought about
talking to Virtualbox upsream and going through the instructions for
debugging such issues. At least the bug shows no evidence of that.
That's misleading, it's only today that someone posted a supposition it *might* be
VirtualBox specific. But comment 2 is from one of the anaconda developers who has seen
this also, and AFAIK he doesn't use VirtualBox, nor do any anaconda developers that
I'm aware of (meanwhile I've also not seen them suggest the slightest hint of
disapproval or skepticism of vbox based bugs or testing). So it's uncertain that this
is only a VirtualBox bug.
Another way to narrowly carve this would be if "nomodeset" in either BIOS or
UEFI mode boot allows it to work, then we shouldn't block even if the problem were to
occur with guest additions built (which of course taints the kernel and leads to a more
complicated troubleshooting process).
This action has to come from Virtualbox users. Anyone else is
unlikely
to set up a testing environment (which is a pretty invasive thing to do
with vbox and unlikely to work with recent kernels) to work on a bug he
or she personally does not care for.
There are two dangerous flaws with this line of logic:
1.
There are a number of QA testers who predominately use VirtualBox for testing Fedora; and
they (including me) tick a box in a test matrix to indicate whether a particular test has
passed or failed. The suggestion that VirtualBox bugs shouldn't block, but tests that
base in VirtualBox should be accepted is a contradiction. Yes thank you I'll take the
good result, but the bad result doesn't matter.
2.
We have an ecosystem where many people of different interests and skill sets do different
things, and this enriches the ecosystem and makes it more valuable than the individual
skill sets alone. People do things that aren't even directly valuable to themselves,
but they do it anyway because they're good at it, and it's for the common good.
What goes around comes around.
The attitude you are describing is "every man for himself, if you want something
done, do it yourself" and distinctly so by singling out the VirtualBox users. This is
not common good based. The equivalent would be me saying, OK, screw it, I'm not going
to test anything anymore. If it's broken, I'm not filing bugs. I'm not going
to try and trouble shoot it. I'll just go do something else, or find an alternative
that works right now. I'll let other people do that leg work, because I don't want
to do it, and I don't see myself as part of something bigger. It's only about me.
So be careful what you ask for. I really don't think this attitude is going to help
with the attrition problem.
Chris Murphy