I have long been looking for a simple way to display the current FPS in games (without direct support in the game), similar to what FRAPS or other tools do in Windows. For Linux, I haven’t had too much luck. There are not many tools for this and usually there are some problems with them – either they are not packaged and complication is difficult, or they don’t work reliably, or they can’t display FPS overlay in the game, just log to a file. But this weekend, I have finally been lucky.
I have stumbled upon an older article from Phoronix: Gallium3D Gets A Heads-Up Display For Information. Gallium3D is a graphics acceleration framework that is currently used by radeon and nouveau drivers. By simply setting an environment variable, you can get a live on-screen overlay displaying lots of useful information:
This is pretty amazing and it does exactly what I was looking for. The usage is really simple – to see the available options, just run:
$ GALLIUM_HUD="help" glxgears Syntax: GALLIUM_HUD=name1[+name2][...][:value1][,nameI...][;nameJ...] Names are identifiers of data sources which will be drawn as graphs in panes. Multiple graphs can be drawn in the same pane. There can be multiple panes placed in rows and columns. '+' separates names which will share a pane. ':[value]' specifies the initial maximum value of the Y axis for the given pane. ',' creates a new pane below the last one. ';' creates a new pane at the top of the next column. Example: GALLIUM_HUD="cpu,fps;primitives-generated" Available names: fps cpu cpu0 cpu1 cpu2 cpu3 samples-passed
In Fedora 20, only basic options like fps and cpu are available. In Fedora Rawhide with newer graphics stack, there are many more options. But I’m fully content with just the basic ones. Now I can run games like this:
$ GALLIUM_HUD="fps,cpu+cpu0+cpu1+cpu2+cpu3:100" mygame
And I have pretty two graphs of FPS and CPU usage. You can run steam the same way, and then see the overlay on each game started from it. And, as a bonus, you can even run totem or vlc (with GL output) like this and see actual FPS of your video rendering :-)
I’m really excited about this. This is how I imagine a modern operating system to look like – useful features directly integrated into its core and very easily accessible (hell, it can’t get even easier than setting an environment variable!). Thanks Marek Olšák and AMD for implementing this. You really made my day.
The only drawback is that because it’s implemented in Gallium3D, it works only on Gallium3D-enabled drivers, which means opensource AMD and Nvidia drivers. No binary drivers and no Intel drivers can benefit from this. Marek explained that it had been very simple to implement this inside Gallium3D, but it would be very tricky to implement this on a level that would affect all the drivers. So there you have it, the opensource drivers now have a killer feature that proprietary drivers don’t :-) Just the Intel situation is unfortunate, maybe they’ll reconsider this some time in the future.
Last week I’ve written about my experience with AMD Radeon R9 270 card in Fedora 20. I have received much advice and feedback in the comments below and some people nudged me to try the latest opensource driver (it’s been a month since Fedora 20 release and OSS world clearly moves fast). So that’s what I did. This post is a follow-up to the previous one, just containing information about the latest changes in the RadeonSI driver. I haven’t tested Catalyst, because I already covered the latest version in the previous article and I don’t expect any major changes just by changing Fedora version.
I did all my testing on Fedora Rawhide (to be Fedora 21 in a distant future). In order to get newer OpenGL support, I used llvm 3.4 packages – those are not yet pushed to Rawhide’s repository, but they should be hopefully merged soon and are available in a special build tag for the moment. I used mesa git 2014-01-10, xorg-x11-drv-ati git 2014-01-12 and xorg-x11-glamor git 2014-01-15 (including a patch for faster gtk lines drawing) – all of this compiled on a machine with llvm 3.4. I was running on nodebug kernel 3.13 rc8 (beware of my mistakes). Packages for S3TC compression (libtxc_dxtn) were installed.
The changes in RadeonSI since Fedora 20
These are the major changes that I spotted in the short time:
- Dynamic power management is enabled automatically. You no longer need to adjust the kernel command line, the card scales its speed according to the load automatically. This is brought by kernel 3.13. One less thing to care about, great.
- GTK primitives rendering is much faster. The developers were very active in addressing the issue and provided several patches. They are not yet committed into the main branch, but one of them is now even included in Fedora packages by default. The rendering speed is not yet on par with other drivers (as you can see in the tests below), but it’s at least an order of magnitude faster. I have no problems with LibreOffice Calc or Motif-like GUIs anymore, everything runs perfectly. Many thanks to radeonsi developers.
- You’ll get OpenGL 3.1/3.0 version support instead of OpenGL 2.1. This is great news, because it allows more games to run, especially the commercial ones. There’s still a long way to go to the current OpenGL 4.4 specification, but this helps with compatibility a lot.
- There are some desktop rendering glitches. I’ve seen a small rendering issues with message tray icons in GNOME. Some of the icons sometimes became invisible (totally transparent). You could still click on them, but you could not see them. I’ve also seen others report this problem, so I assume it’s known and hopefully will be fixed soon. I haven’t seen this problem back on Fedora 20. There are also some other minor glitches, for example very occasionally there is a graphical artifact instead of some letter rendered on the web by Firefox. But that is very rare, can be fixed by highlighting the text and happens on Fedora 20 as well.
Update: The invisible icon bug seems to have been fixed the next day after I published this. I still see some issues, but they are most probably related to GNOME in general and not to radeonsi driver.
In general I’ve been very pleased by the recent development, the developers are responsive and they have improved the driver a lot recently.
I have some good news and some bad news. The good news is that the number of games that run and their performance have improved substantially. And I mean substantially. On Fedora 20 half of my Steam games crashed or there were some serious issues with them. Now only 10% crash (some of that might be caused by llvm 3.4, according to the crash messages) and another 15% are either slower or experience graphical issue. However, the majority now runs just fine. I attribute this mainly to the OpenGL 3.1/3.0 support. Here’s my updated list of Steam games I tested, compare Fedora 20 RadeonSI column with Fedora Rawhide RadeonSI column:
Performance-wise there have been some improvements as well, probably at around 10% or so in average. You can see the updated Phoronix Test Suite graphs below. The commercial games felt a bit better as well.
The bad news is that we’re still not there. The situation improved sharply, but there’s still a large percentage of games which can’t be played. The performance also varies wildly. For example Dota 2 was totally unplayable even with low quality settings, you could see 5-10 FPS easily in larger battles. On the other hand, Left 4 Dead 2 or Team Fortress 2 seemed very well playable (I spent max 5-10 minutes in these games, so the real gameplay results might vary).
If you want to play on Linux with an AMD graphics card and an opensource driver, you still need to be a modest gamer. You must not mind if some of your games run very slow or not at all. However, the recent progress has been very good and it seems that AMD together with community developers try real hard to provide a fully functional opensource driver. I’m very glad for that. Hopefully Linux users won’t need to choose between freedom (plus out-of-the-box functionality) and performance in the near future. By the way, I decided to keep the AMD card in order to support OSS-compatible companies.
I have a brand new AMD graphics card and I assume someone might be interested in how it works in Fedora 20. This post summarizes my experiences with it.
A week ago I’ve bough MSI Radeon R9 270 GAMING 2G. It’s an upper mid-range card and most new games should run on it reasonably well on high details. In Fedora there are two choices – you can either use the default open-source radeonsi driver, or you can install proprietary catalyst driver. I have tried general system functionality and also a lot of games (through Steam) on both drivers.
The GNOME desktop itself works without a glitch. Everything is fluent and I haven’t noticed any problems whatsoever. However, there are some other issues:
- You need to enable dynamic power management manually. Without DPM, the card runs at the lowest speed profile all the time. Enabling it is really simple, you just add radeon.dpm=1 to the kernel command line. From kernel 3.13 this should be enabled automatically. With DPM, the card automatically switches between low and high speed profiles depending on its utilization. DPM worked without problems for me. More information.
- GTK primitives rendering is extra slow. I stumbled upon this when I ran gtkperf test, gtk primitives (like lines and circles rendering) is 4 or 5 orders of magnitude (!!) slower than with catalyst (or the integrated Intel graphics card). Fortunately, these primitives are not used much. They were used in old GUI frameworks like Motif. However, you can still find it here and there, for example in some old software installers or in game settings dialogs (like Amnesia: The Dark Descent). Operating such interfaces is really slow. Unfortunately, there is one further example where GTK primitives are used, which is LibreOffice Calc. Even medium-sized spreadsheets are unusable with radeonsi driver :-( I might still find some other problematic software, but up to date, I’ve found only the LibreOffice Calc to be a quite show-stopper. Freedesktop bug 68524, freedesktop bug 71813.
- Fan speed is higher than with Catalyst. It seems that there are three ways how to affect graphics card fan speed – there is a profile in its vbios, there is another profile in the driver and then there can be a user defined profile. The vbios profile kicks in during computer start and boot, the driver profile kicks in during operating system video initialization (setting graphical mode) and user profile can be enabled by a custom application. Radeonsi doesn’t currently support driver or user defined profiles, so only the vbios profile is used. Unfortunately, the manufacturer (MSI) set the default idle fan speed to 40%, so with radeonsi your fan speed will never go below that, no matter how cool the card is. It’s not loud, but it’s audible. With catalyst driver, the fan speed in idle is 18%, which is truly inaudible. Quite a pity. Freedesktop bug 73338.
When it comes to gaming, the current state is very very sub-optimal. Even though the usual open source games available in Fedora repositories (like OpenArena and Xonotic) run very well, a lot of commercial games simply crash. I suppose they require some OpenGL extensions that are not implemented in the driver, or they simply hit some bugs in the driver. If they run, the performance is quite bad. I’ve tested quite a few games and compiled a list showing how well they run, it’s available here. Basically any modern 3D game didn’t run for me (crashed or performed poorly). I’ve also made some benchmarks, see below.
If you want to use the catalyst driver, prepare for some serious headaches:
- The driver is no longer available in RPMFusion. The maintainer orphaned the pacakge and no other volunteer appeared. That means you’ll need to download the official installer from AMD website and install it with every kernel update. You won’t receive new kernel modules automatically from RPMFusion, nor you will have have akmod (automatic module compilation) setup easily for you. FedoraForums discussion.
- GNOME doesn’t work with Catalyst in Fedora 20. GNOME shell and apps were compiled with Wayland support, which uses libEGL library. Catalyst currently doesn’t ship this library, so all the software crashes. At least that’s my understanding. You can either use Fedora 19, or some other desktop environment (I don’t know about KDE, but XFCE should work; however, you still can’t use any of affected apps even in a different environment), or download packages recompiled without wayland support from untrusted sources (not recommended, and of course it also prevents you from updating your system). This sucks really hard, it’s a show-stopper for most people . FedoraForums discussion, RPMFusion bug 2914, GNOME bug 712340, AMD bug 949, Phoronix discussion.
- You can’t switch from game to desktop. If you hit Alt+Tab during gameplay (in games which support it), you don’t see the regular switcher widget. When you hit Win key (in GNOME), you don’t see the overview. Everything actually happens (you can tell because your mouse cursor changes), but you see the game all the time (even though your keyboard input might control a completely different application). This means that you effectively can’t switch your game and your desktop/other apps (even though it actually happens), because the image does not redraw.
Update: With Catalyst 13.11 Beta 9.95 this works much better. If you hit Win key, you see the overview mode and can switch applications. If you hit Alt+Tab, you see the switcher widget, but you need to operate it with a mouse. Sometimes it’s quirky – in Dota 2 I needed to hold Alt+Tab for several seconds to manage to switch, in Amnesia I saw a black screen for 10 seconds after returning to game, and Champions of Regnum behaved like an always-on-top window. Also in the overview mode the game thumbnail is not correctly updated. But generally it works.
- Video overlays don’t work in Totem. If you watch a fullscreen video in Totem and wiggle your mouse, you don’t see any overlay widgets, even though you can click on them (blindly). So in order to jump forward or backward in the video, or adjust the volume, you need to unfullscreen it. I think this is connected to the previous problem, again it’s some kind of overlay over video/GL context and it is not rendered correctly. VLC works fine, though.
Update: This seems fixed with Catalyst 13.11 Beta 9.95.
- You can’t control your desktop over VNC. If you set up a VNC server and connect to it, you won’t receive any screen updates (even if you want to force them from the client). You can click on stuff, but you see just a still picture. If you reconnect, you see an updated (and again still) image. VNC is simply unusable. I tried only the GNOME integrated server, it might work better with other servers, I don’t know.
Gaming is much better with catalyst driver. Most games work, and their performance is good. According to some online benchmarks, the Linux performance is still lower than Windows performance, but the gap is definitely smaller than between radeonsi and catalyst. With a few games I had graphical glitches issues and in some games I saw some stuttering (FPS is high but you experience mini-lags every short while). But in general it simply works. Again, the list of games with some notes is here.
Phoronix Test Suite
Because I’m a benchmark freak, I tried to run some tests and compare the results between radeonsi, catalyst, and my integrated Intel graphics card. I was looking for some automated way of doing it and I’ve found Phoronix Test Suite. It’s a neat piece of software, packaged in Fedora, and allowed me to simply (in an automated fashion) run a series of tests and even drew graphs of the results for me. It’s simple to operate and I really recommend it. Of course it has some rough edges, but what doesn’t.
Most of the tests consist of open source software, and as I said before, the radeonsi driver performs really well with those and generally doesn’t crash. So these results look quite optimistic in this regard. In real life, however, most commercial apps don’t perform as well or crash immediately, as mentioned before. I didn’t benchmark those, because it seemed as too much manual work. I think the current test set is enough for a simple overview. If you see a missing item in the results, it means that either the test crashed on that driver, or was so slow that I couldn’t finish it in reasonable time (the GTK primitives rendering).
Here’s a trailer of the result graphs. Full results are here.
The situation is far from perfect. I really understand why Steam survey shows only 1% of Linux players in its user base. It’s hard to play in Linux with such graphical drivers. I bought an AMD card because I wanted to support them in releasing hardware documentation and hiring opensource driver developers (they do both, same as Intel, and unlike Nvidia). Nevertheless after my week-long experience (maybe I should say misery?) I really considered swapping the card for Nvidia GeForce GTX 660 (same price, same performance). Still, I’m reluctant to do it. I had bad experience with binary nvidia driver in the past, and I have had utterly abysmal experience with nouveau driver in recent years. I don’t know if the nvidia driver has some similar issues with alt+tab switching, video overlays in totem or vnc redraws (or some other issues, I would be very interested to hear that in the comments), but I know for sure that I don’t want to end up with nouveau if I ever discover a show-stopper in nvidia driver. Radeonsi driver is definitely light years ahead of nouveau. Nvidia announced they would help nouveau last fall, they released a single piece of basic documentation, and since then I’ve seen exactly nothing to happen. They don’t seem to keep their promise. With radeonsi, at least I can try to help the driver by submitting bug reports, because the developers are not kept in the dark. And Marek Olšák has been doing some amazing improvements and fixes lately. And for gaming, there’s always… ugh… Windows.
Update: Read my follow-up article with the most recent radeonsi driver here.
Some time ago I compared disk drivers performance in KVM. Today I compared different storage formats – raw and qcow2. Let’s have a look:
Test procedure: Create an empty 10 GB image, attach to VM using VirtIO driver, boot F20 Alpha Live x86_64, measure the time of installation. Repeat installation once again, this time reusing the existing image (instead of creating a new one). Do this for both formats.
raw 1st pass 2:36 raw 2nd pass 2:38 qcow2 1st pass 2:36 qcow2 2nd pass 2:44
As you can see, the results are very much the same. It seems it doesn’t matter much which format you use.
But, qcow2 format has some nice additional features, like copy-on-write cloning. If I need to test something very quickly in my existing VM and then revert the changes back, this is the easiest way:
$ cd /var/lib/libvirt/images $ mv f19.qcow2 f19.qcow2_orig $ qemu-img create -f qcow2 -b f19.qcow2_orig f19.qcow2 Formatting 'f19.qcow2', fmt=qcow2 size=10737418240 backing_file='f19.qcow2_orig' encryption=off cluster_size=65536 lazy_refcounts=off $ # Run the VM now and do your tasks $ mv f19.qcow2_orig f19.qcow2
I have just discovered GnomeOSTree (I’ve heard about it before, but never tried it). It allows you to run an absolutely fresh version of GNOME (checked out from git the very day) in a virtual machine. This is perfect for
- experimenting with new features
- checking whether a bug still exists in the development version
- checking whether a bug fix is correct, without waiting for a distribution package update
I’ve just played with it for 10 minutes, so I might be missing a lot of things, but this seems to be a very useful tool for anyone testing and reporting GNOME bugs. It’s extremely easy to set up, you just download a VM disk image and import it into virt-manager. Later you can update it from inside the system. Try it!
Another quarter is gone, let’s see how much testing of proposed updates in Fedora we have done. The purpose of this testing is to make sure that broken updates don’t enter our stable (or soon-to-be-stable) Fedora releases. The test feedback is managed inside Bodhi application and here are the statistics for the recent quarter:
Test period: Q2 2013 (2013-04-01 – 2013-06-30)
1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.
When compared to Q1 2013, the number of reporters remained steady, but the number of reports increased almost twofold. That is amazing, I suspect it’s directly related to the Fedora 19 stabilization cycle and release.
The top-performers have almost an even score, which is great to see. They are Adam Williamson (adamwill), Reindl Harald (hreindl) and Igor Gnatenko (ignatenkobrain). Thank you guys for your outstanding and steadfast performance!
It’s also interesting to see that in the top 15 list there are only 4 Red Hatters (Adam, Kevin, Alexander and me), all the rest are community participants. I love that fact very much. Testing might not always be fully engaging, but still, paid employees are the minority here. What a strong community.
If you see yourself in the table, or if you are somewhere below the threshold, thank you. Your effort makes Fedora stable and reliable.
If you haven’t participated yet, maybe it’s time to give it a try? You can start today! Just read QA:Updates_Testing and ask any questions in #fedora-qa on IRC or test list. We would love to see even more people involved.
When reading the statistics, please take it with a grain of salt. Not all numbers are directly comparable. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by these scripts.
Fedora 19 the Schrödinger’s Cat is out of the box, and alive! I have again gathered some interesting statistics about QA contributions, this time during the Final phase (between Beta and Final release).
Fedora 19 Final – wiki matrices
This is the list of people who filled in our release validation wiki matrices (Install, Desktop and Base), which are posted for every test compose (and release candidate) that we create. The purpose is to see which areas have been thoroughly tested and which were not.
Test period: Fedora 19 Beta – Fedora 19 Final
Unique referenced bugs: 58
|Name||Reports submitted||Referenced bugs1|
|robatino||259||929177 946964 958426 958427 972025 972046 974050 974052 975227 975230 975324 975325 976280 976281 977669 977671 977715 977732 978114 978124 978125 979171 979172 (23)|
|nonamedotc||127||972225 977879 (2)|
|adamwill||103||858270 892178 975800 978008 (4)|
|kparal||103||973068 974032 974038 977715 977816 977962 (6)|
|lbrabec||49||855824 858270 977962 978298 (4)|
|jpospisi||48||964586 975483 (2)|
|pkotvan||23||969684 975813 (2)|
|jsedlak||19||973747 975375 978346 (3)|
|lnovy||16||743281 858270 (2)|
|mmarhefk||16||892178 959796 975521 (3)|
|werkman||5||971109 971255 976034 (3)|
|konradr||2||977974 977987 978036 (3)|
1 This is a list of bug reports linked to the wiki results. They don’t have to be reported by that concrete person.
Who would have thought… Andre Robatino (robatino) is at the top again. It’s also very nice to see how many bugs he referenced during his testing. The more referenced bugs the more publicity, the more likeliness that someone reproduces them, the more likeliness someone fixes them. Thanks, Andre!
The community participation list continues with nonamedotc, who provided an amazing number of test case results as well. Then there is a long list of Red Hatters, the highest score split between Adam Williamson (adamwill) and Kamil Páral (kparal) (a.k.a. me). Since I referenced more bugs, I consider myself a winner :-P “I only believe in statistics that I doctored myself.” :)
The community participation continues with Bob Lightfoot (boblfoot), who had been greatly active during Beta, John Reiser (jreiser), Thomas Gilliard (satellit) and others. Thank you, everyone.
Fedora 19 Final – Bugzilla
This is a trimmed list of people who reported bugs into Bugzilla against Fedora 19 in the specified time period. When compared to Fedora 19 Beta, the numbers went up again, especially the number of reporters. That’s really great.
Test period: Fedora 19 Beta – Fedora 19 Final (2013-05-29 – 2013-06-28)
New reports: 1486
|Name||Reports submitted1||Excess reports2||Accepted blockers3|
|IBM Bug Proxy||31||2 (6%)||0|
|Mark Salter||31||2 (6%)||0|
|Adam Williamson||27||1 (3%)||2|
|quickbooks.office at gmail.com||27||1 (3%)||1|
|David Woodhouse||23||0 (0%)||0|
|Kamil Páral||22||2 (9%)||4|
|Andre Robatino||21||18 (85%)||1|
|Zbigniew Jędrzejewski-Szmek||17||0 (0%)||0|
|Dan Mashal||16||4 (25%)||0|
|Karel Volný||16||0 (0%)||0|
|Vojtěch Boček||13||0 (0%)||2|
|Emmanuel Pacaud||13||0 (0%)||0|
|Jan Sedlák||11||0 (0%)||0|
|Lukas Brabec||11||1 (9%)||0|
|Martin Holec||11||2 (18%)||0|
|Tim Waugh||11||0 (0%)||0|
|A.J. Werkman||10||0 (0%)||0|
|Florian Weimer||10||0 (0%)||0|
|Heiko Adams||10||0 (0%)||0|
|Joachim Backes||10||3 (30%)||0|
|Chris Murphy||9||0 (0%)||1|
|Bojan Smojver||9||0 (0%)||0|
|Diogo Campos||9||0 (0%)||0|
|Jonas Thiem||9||0 (0%)||0|
|David Jaša||8||1 (12%)||0|
|Dean Hunter||8||1 (12%)||0|
|Endi Sukma Dewata||8||2 (25%)||0|
|Jeff Bastian||7||1 (14%)||1|
|Jiří Martínek||7||1 (14%)||0|
|Marcus Moeller||7||3 (42%)||0|
|Matthew Miller||7||0 (0%)||0|
|Simon Lewis||7||1 (14%)||0|
|Mark Hamzy||6||0 (0%)||1|
|Kalev Lember||6||1 (16%)||0|
|Krzysztof Daniel||6||0 (0%)||0|
|Russ Anderson||6||1 (16%)||0|
|Siddhesh Poyarekar||6||0 (0%)||0|
|James Heather||5||0 (0%)||1|
|Jiri Eischmann||5||1 (20%)||1|
|Michael Scherer||5||0 (0%)||1|
|Alexey Derlaft||5||2 (40%)||0|
|Andrea Oliveri||5||1 (20%)||0|
|Björn Esser||5||0 (0%)||0|
|D. Charles Pyle||5||0 (0%)||0|
|Dennis Gilmore||5||0 (0%)||0|
|Edgar Hoch||5||0 (0%)||0|
|Flóki Pálsson||5||1 (20%)||0|
|Francisco de la Peña||5||1 (20%)||0|
|Joshua Holm||5||0 (0%)||0|
|Konrad Rzeszutek Wilk||5||0 (0%)||0|
|Lukas -krtek.net- Novy||5||2 (40%)||0|
|Matthias Clasen||5||0 (0%)||0|
|nonamedotc at gmail.com||5||2 (40%)||0|
|Paul Whalen||5||0 (0%)||0|
|Reartes Guillermo||5||0 (0%)||0|
|Vít Ondruch||5||0 (0%)||0|
|Álvaro Castillo||5||0 (0%)||0|
|Štefan Gurský||5||0 (0%)||0|
|…and also 547 other reporters who created less than 5 reports each, but 834 reports combined!|
1 The total number of new reports (including “excess reports”). Reopened reports or reports with a changed version are not included, because it was not technically easy to retrieve those. This is one of the reasons why you shouldn’t take the numbers too seriously, but just as interesting and fun data.
2 Excess reports are those that were closed as NOTABUG, WONTFIX, WORKSFORME, CANTFIX or INSUFFICIENT_DATA. Excess reports are not necessarily a bad thing, but they make for interesting statistics. Close manual inspection is required to separate valuable excess reports from those which are less valuable.
3 This only includes reports that were created by that particular user and accepted as blockers afterwards. The user might have proposed other people’s reports as blockers, but this is not reflected in this number.
The top reporters are nicely and evenly distributed, there are no extreme performers as in the wiki statistics. The top position share IBM Bug Proxy and Mark Salter. Mark reported a number of build failures for ARM architecture. I assume IBM Bug Proxy is probably a shared account among IBM employees who care about Fedora development – they reported a number of anaconda, kernel and boot issues. It’s always nice to see other companies involved in raising the Fedora quality – welcome, IBM :-)
When it comes to general bug reporting, the top Red Hatter is Adam Williamson. As for the community, quickbooks.office reported the same number of bugs, most of them being SELinux error duplicates. Mikhail closely follows with a much more interesting mix of bug reports, which also applies for David Woodhouse. The community list follows with Andre Robatino (mostly fake bug reports for test purposes), Zbigniew Jędrzejewski-Szmek, Dan Mashal and others.
It’s great to see so many bug reports and so even distribution of the top reporters. Thanks, all of you.
Fedora 19 Beta – updates testing
This is a trimmed list of people who provided feedback in Bodhi for all updates proposed into Fedora 19 in the specified time period. The purpose is to make sure that broken updates do not enter the stable repository and the release continuously stabilizes. The number of testers increased considerably again as compared to Beta.
Test period: Fedora 19 Beta – Fedora 19 Final (2013-05-29 – 2013-06-28)
1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.
A new star has emerged, Igor Gnatenko (ignatenkobrain) completely dominated here. Great job, Igor! The top performing Red Hatter was, yet again, Adam Williamson (adamwill).
The top community list, apart from Igor, also contains nonamedotc, Kalev Lember (kalev), bitlord, T.C. Hollingsworth (patches), quickbooks, Piotr Drąg (raven), and others. It’s great to see so many people involved, because testing proposed updates and providing karma is one of the easiest way to contribute, yet extremely important at the same time. Thanks to anyone who contributed!
For most parts, the number of reports stays similar to Beta, but the number of people involved rose considerably. Beta release seems to be very attractive to the Fedora community and rightly so, it’s the last step before everything is pronounced stable. We’re glad to see so many people involved in release testing and we hope that we will see you again in Fedora 20 cycle!
In the meantime you can help as well – for example testing the proposed updates for stable Fedora releases is as useful, maybe even more important, than for releases in development. You can also play with Rawhide and help us find the bugs well in advance. There is a lot of possibilities – if it sounds interesting to you, be sure to have a look at QA/Join, follow the announcements and talk to us in #fedora-qa on IRC and test list. Your involvement will help not only Fedora and its users, but the whole Linux ecosystem. Thanks!
When reading the statistics, please take it with a grain of salt. The numbers are not directly comparable. People might see some reports as more valuable than others. Some people tested a lot of components, but haven’t found many problems (but that also helps). Some people used their skills in other areas than those mentioned. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by these scripts.