[personal profile] mjg59
Eric (a fellow Fedora board member) has a post describing his vision for what Fedora as an end goal should look like. It's essentially an assertion that since we have no idea who our users are or what they want, we should offer them everything on an equal footing.

Shockingly enough, I disagree.

At the most basic level, the output of different Special Interest Groups is not all equal. We've had issues over the past few releases where various spins have shipped in a broken state, because the SIG responsible for producing them doesn't have the resources to actually test them. We're potentially going to end up shipping F20 with old Bluetooth code because the smaller desktops aren't able to port to the new API in time[1]. Promoting these equally implies that they're equal, and doing so when we know it isn't the case is a disservice to our users.

But it's not just about our users. Before I joined the Fedora project, I'd worked on both Debian and Ubuntu. Debian is broadly similar to the current state of Fedora - no strong idea about what is actually being produced, and a desire among many developers to cater to every user's requirements. Ubuntu's pretty much the direct opposite, with a strongly defined goal and a willingness to sacrifice some use cases in order to achieve that goal.

This leads to an interestingly different social dynamic. Ubuntu contributors know what they're working on. If a change furthers the well-defined aim of the project, that change happens. Moving from Ubuntu to Fedora was a shock to me - there were several rough edges in Fedora that simply couldn't be smoothed out because fixing them for one use case would compromise another use case, and nobody could decide which was more important[2]. It's basically unthinkable that such a situation could arise in Ubuntu, not just because there was a self appointed dictator but because there was an explicit goal and people could prioritise based on that[3].

Bluntly, if you have a well-defined goal, people are more likely to either work towards that goal or go and do something else. If you don't, people will just do whatever they want. The risk of defining that goal is that you'll lose some of your existing contributors, but the benefit is that the existing contributors will be more likely to work together rather than heading off in several different directions.

But perhaps more importantly, having a goal can attract people. Ubuntu's Bug #1 was a solid statement of intent. Being freer than Microsoft wasn't enough. Ubuntu had to be better than Microsoft products on every axis, and joining Ubuntu meant that you were going to be part of that. Now it's been closed and Ubuntu's wandered off into convergence land, and signing up to spend your free time on producing something to help someone sell phones is much less compelling than doing it to produce a product you can give to your friends.

Fedora should be the obvious replacement, but it's not because it's unclear to a casual observer what Fedora actually is. The website proudly leads with a description of Fedora as a fast, stable and powerful operating system, but it's obvious that many of the community don't think of Fedora that way - instead it's a playground to produce a range of niche derivatives, with little consideration as to whether contributing to Fedora in that way benefits the project as a whole. Codifying that would actively harm our ability to produce a compelling product, and in turn reduce our ability to attract new contributors even further.

Which is why I think the current proposal to produce three first-class products is exciting. Offering several different desktops on the download page is confusing. Offering distinct desktop, server and cloud products isn't. It makes it clear to our users what we care about, and in turn that makes it easier for users to be excited about contributing to Fedora. Let's not make the mistake of trying to be all things to all people.

[1] Although clearly in this case the absence of a stable ABI in BlueZ despite it having had a dbus interface for the best part of a decade is a pretty fundamental problem.
[2] See the multi-year argument over default firewall rules and the resulting lack of working SMB browsing or mDNS resolving
[3] To be fair, one of the reasons I was happy to jump ship was because of the increasingly autocratic way Ubuntu was being run. By the end of my involvement, significant technical decisions were being made in internal IRC channels - despite being on the project's Technical Board, I had no idea how or why some significant technical changes were being made. I don't think this is a fundamental outcome of having a well-defined goal, though. A goal defined by the community (or their elected representatives) should function just as well.

Date: 2013-08-22 06:49 pm (UTC)
From: (Anonymous)
I moved away from Fedora because I got bored of waiting for the bugs I filed to be looked at. One in particular remained unassigned for several months and spanned two releases (f18 and f19).

Whenever I file a new bug in Ubuntu, there's no guarantee that it's going to be fixed, but at least somebody takes looks at it and tries to help.

No matter what the plans are for the distro, if the support for it is lacking, it won't matter which use cases are covered.

Date: 2013-08-22 07:11 pm (UTC)
From: (Anonymous)
That is amusing as it is my normal experience with Ubuntu - bugs not being looked at or going unfixed, often for years. One simply required a recompile, another had the main binary coredump on startup with a patch published in the Redhat bug tracker. A recent one involved a single character fix and the loss of data, but won't be done due to a lack of a "sponsor". (Apparently it isn't enough for the project to document it as a bug and do a point release.)

Date: 2013-08-22 07:53 pm (UTC)
From: (Anonymous)
I guess I've been lucky so far. I mostly file kernel bugs for hardware related issues. I try to fix user-space programs myself.

My Fedora bug experience is very good

Date: 2013-08-24 06:01 pm (UTC)
From: (Anonymous)
Starting in Fedora 18, I filed a bug about the 3.9.x kernels panicking under EFI boot.

There was a lot of attention to the bug, and Fedora developers resolved it very quickly, even though the trouble was with the upstream (the Linux kernel).

It was a great experience that, for me, instilled a lot of faith in Fedora.

Time to repair.

Date: 2013-08-22 10:02 pm (UTC)
From: (Anonymous)
I am waiting since Fedora 17 for responses to bugs that I registered. There is a glance at first, and then bingo, nothing.
When Fedora 17 reached end-of-life, the Bugs that are release independent got wiped. For most of them, I promoted them to F18, then to F19

Fedora relies on volunteers mainly to do the testing and reporting. There is no central clearing house that redistributes the bug reports to Gnome, kde, Linux, Xfce, etc.

Moreover, there is no ageing of bug reports, so that older ones get raised in priority.

For maximum benefit to users, the quick fix bugs should be highest in priority, with those deemed to be longer in fix time, below, and major effort bugs lowest in priority. The idea, as it is done in every industry, is to satisfy the most users by not respecting FIFO.

Re: Time to repair.

Date: 2013-08-23 02:19 am (UTC)
From: (Anonymous)
Take a look at this list


It is huge, and yet a LOT of bugs are assigned to someone. What I'd like is to every bug to have a fair chance of being looked at. I don't mean fixed or triaged, just looked at.

Date: 2013-08-23 09:59 am (UTC)
reddragdiva: (flame war)
From: [personal profile] reddragdiva
Mine is the opposite - a bug marked NEEDINFO and asking me to upgrade my BIOS try again with 10.04, seven months after I'd noted that my workaround had to upgrade to 12.04. The bug in question existing only in the Ubuntu 10.04 kernel, not in Debian and not in the corresponding mainline kernel. But apparently asking me to trash a working system for a bug that Canonical pretty clearly added is reasonable.

Date: 2013-08-24 04:03 am (UTC)
From: (Anonymous)
Bug handling in Fedora is pitiful. Bugzilla forces you to tag issues against a release and when that release goes out of support, all issues are swept under the carpet, unless someone updates them. From the perspective of many bug reporters, after they've reported it, it's someone else's problem and often the maintainers don't even bother making a single reply and are barely aware it exists. Automation is great, but putting the onus on people to clean up after a crazed ticket-closing bot is *anti-automation*. It creates extra work and obscures real bugs.

Huge numbers of bugs like this still exist, and no one knows, because of some utterly moronic logic that if no one has done any Bugzilla housekeeping recently, it's unimportant. How the fuck can you keep a list of known issues with such a ridiculous triaging system?


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Member of the Linux Foundation Technical Advisory Board. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags