Developer focus for Fedora workstation

[Chris Murphy]

On Aug 21, 2014, at 2:20 PM, Lars Seipel <lars.seipel at 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