It took me a while, but finally I have further data regarding Fedora 18 Final testing contributors. Last time I presented a list of people who helped out with QA wiki matrices, this time I have Bugzilla statistics.
The results are pretty interesting. Over 800 people reported bugs between Fedora 18 Beta and Final, creating over 2300 new bugs in total. Those are stunning numbers for a 6-week period including Christmas holidays. A trimmed list of top contributors is below:
Test period: 2012-11-29 – 2013-01-15 (Fedora 18 Beta release – Fedora 18 Final release)
Total number of reporters: 814
Total number of new reports: 2311
|Name||Total reports submitted1||Excess reports2||Accepted blockers3|
|Michael Scherer||59||1 (1%)||0|
|Reartes Guillermo||53||3 (5%)||0|
|Jan Teichmann||34||28 (82%)||0|
|Kamil Páral||31||2 (6%)||2|
|Steve Tyler||29||0 (0%)||3|
|Aleksandar Kostadinov||29||7 (24%)||0|
|Chris Murphy||25||0 (0%)||7|
|Gene Czarcinski||25||2 (8%)||0|
|Adam Williamson||24||0 (0%)||5|
|Dean Hunter||24||11 (45%)||0|
|Kay Sievers||22||3 (13%)||0|
|Michal Schmidt||19||1 (5%)||0|
|Heiko Adams||18||3 (16%)||0|
|Andre Robatino||17||15 (88%)||0|
|Florian Weimer||17||1 (5%)||0|
|Štefan Gurský||17||0 (0%)||0|
|Niki Guldbrand||16||0 (0%)||0|
|Flóki Pálsson||14||2 (14%)||0|
|mariolinux at alice.it||14||0 (0%)||0|
|Braden McDaniel||13||2 (15%)||0|
|Cole Robinson||12||1 (8%)||0|
|Brian J. Murrell||11||0 (0%)||0|
|Mikolaj Izdebski||11||0 (0%)||0|
|Petr Schindler||10||0 (0%)||1|
|IBM Bug Proxy||10||0 (0%)||0|
|Jan Vcelak||9||0 (0%)||1|
|Tommy He||9||0 (0%)||1|
|Carlos Soriano||9||1 (11%)||0|
|Hin-Tak Leung||9||0 (0%)||0|
|Lingzhu Xiang||9||0 (0%)||0|
|Michael Schwendt||9||2 (22%)||0|
|sheepdestroyer at gmail.com||9||0 (0%)||0|
|Tim Waugh||9||0 (0%)||0|
|xset1980 at hotmail.com||9||2 (22%)||0|
|Matthew Miller||8||1 (12%)||2|
|abyss.7 at gmail.com||8||1 (12%)||0|
|Ankur Sinha (FranciscoD)||8||0 (0%)||0|
|D. Charles Pyle||8||0 (0%)||0|
|Dan Mashal||8||0 (0%)||0|
|Jean-François Fortin Tam||8||0 (0%)||0|
|Leslie Satenstein||8||1 (12%)||0|
|Luya Tshimbalanga||8||2 (25%)||0|
|M. Edward (Ed) Borasky||8||0 (0%)||0|
|Miro Hrončok||8||1 (12%)||0|
|Munteanu Victor Ion||8||0 (0%)||0|
|pizza306 at gmail.com||8||2 (25%)||0|
|quickbooks.office at gmail.com||8||0 (0%)||0|
|Richard W.M. Jones||8||1 (12%)||0|
|skkd.h4k1n9 at yahoo.de||8||0 (0%)||0|
|Eric Blake||7||0 (0%)||1|
|Ian Pilcher||7||0 (0%)||1|
|m-redhat at fuglos.org||7||0 (0%)||1|
|Robert Lightfoot||7||4 (57%)||1|
|cornel panceac||7||0 (0%)||0|
|Erwan Bousse||7||1 (14%)||0|
|Joachim Backes||7||2 (28%)||0|
|Mikko Tiihonen||7||0 (0%)||0|
|Amit Shah||6||2 (33%)||0|
|Dave Jones||6||2 (33%)||0|
|Guillaume AMAT||6||1 (16%)||0|
|Ivo Sarak||6||0 (0%)||0|
|Jaroslav Škarvada||6||0 (0%)||0|
|Jens Petersen||6||0 (0%)||0|
|Klaus Lichtenwalder||6||0 (0%)||0|
|Martin Holec||6||1 (16%)||0|
|Matthias Runge||6||0 (0%)||0|
|Milan Bouchet-Valat||6||0 (0%)||0|
|Philipp Dreimann||6||0 (0%)||0|
|Tapani Björg||6||1 (16%)||0|
|W. Michael Petullo||6||0 (0%)||0|
|A.J. Werkman||5||0 (0%)||0|
|Benjamin Kosnik||5||0 (0%)||0|
|Christoph Frieben||5||0 (0%)||0|
|cookies.river at gmail.com||5||0 (0%)||0|
|Fabrice Bellet||5||1 (20%)||0|
|Francesco Frassinelli||5||1 (20%)||0|
|Gerard Ryan||5||0 (0%)||0|
|Gustavo Luiz Duarte||5||0 (0%)||0|
|Jan Sedlák||5||1 (20%)||0|
|Jared Smith||5||0 (0%)||0|
|Josh Boyer||5||0 (0%)||0|
|leigh scott||5||1 (20%)||0|
|Luke Macken||5||0 (0%)||0|
|Nicholas Nachefski||5||0 (0%)||0|
|Orion Poplawski||5||2 (40%)||0|
|Pravin Satpute||5||0 (0%)||0|
|Ralf Corsepius||5||1 (20%)||0|
|Rex Dieter||5||1 (20%)||0|
|Sam Tygier||5||0 (0%)||0|
|satellit at bendbroadband.com||5||0 (0%)||0|
|…and also 710 other reporters who created less than 5 reports each, but 1164 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.
I’m very glad to see that most of the top reporters are in fact not Red Hat employees. That suggests how strong Fedora community is. I’d like to specifically thank these top community contributors, namely Reartes Guillermo, Mikhail, Jan Teichmann, Steve Tyler, Chris Murphy, Gene Czarcinski, Dean Hunter, Heiko Adams, Max, Andre Robatino, Štefan Gurský, Niki Guldbrand and all the others that spent their personal time to help improve Fedora quality.
Of course, kudos also to anyone else who contributed, no matter whether they are mentioned in the matrix above or not. Without you, the bug reporters, we wouldn’t be able to keep Fedora 18 quality up, as it is (hopefully) now. So, thank you!
Recruitment pitch: If you haven’t participated in Fedora 18 release validation, we would love to see you in the Fedora 19 cycle (the test period will start in a month or so) or simply helping out to polish the currently stable Fedora 18 release. Please read QA/Join#Reporting_bugs_in_Fedora_releases, follow the announcements and talk to us in #fedora-qa on IRC and test list.
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 Bugzilla or wiki matrices. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by the stats-bugzilla.py script.
A few days ago I got pretty annoyed at YouTube:
- The video windows are really small, even enlarged. It doesn’t respect available screen size at all. It is impossible to size it arbitrarily.
- Fullscreen is cancelled when you adjust the system volume using hotkeys (Firefox+HTML5+Linux).
- Fullscreen is cancelled when you switch to a different application (HTML5, Flash).
- Fullscreen can’t be used even in a dual-head setup, i.e. run the video on one screen and work on another.
- Entering and leaving fullscreen causes video quality switching every single time (HTML5). That causes a few seconds lag. The only way to work around is to manually select video quality, then it’s not changed forth and back.
The net result: I swear a bloody vendetta to YouTube/Flash/Firefox developers every time I want to watch large videos and do something else (or adjust my volume!) at the same time.
I haven’t found any good solution for this on the Internets, so I created my own. Here’s my glorious bookmarklet:
(I had to create in on an external site, because WordPress doesn’t allow to insert bookmarklets into blogs. So just follow the link).
Drag and drop the button to your bookmarks bar in your browser. Then visit YouTube, open up some video and click the button in your bookmarks bar. The video should reload and fill your whole screen. It should also automatically switch to 720p quality, if available.
This has several advantages:
- Your browser window is fully resizable and the video dimensions change with it.
- If you switch your browser to run in fullscreen, the video still works, even if you switch to a different application. Here we come, multi-head!
- You no longer need to manually force HD video quality.
Some final notes:
- The bookmarklet source is here. Please bear in mind I have zero HTML/JS knowledge. If you have some patches, post them on github.
- Flash is required for this to work. Patches welcome on how to do the same thing with HTML5.
- If you want something else than 720p to be the default, just edit the bookmarklet and change
quality="hd720"to something else.
Fedora 18 development is over and I would like to thank all who contributed to Fedora 18 release testing. Below is a list of contributors together with the number of results they reported into our release validation wiki matrices (Install, Desktop and Base) for the Fedora 18 Final milestone:
|User name||Reports submitted||Referenced bugs*|
|robatino||271||887991 853590 872844 887120 (4)|
|boblfoot||218||889896 890965 886314 883075 889908 885912 893918 891881 879187 873144 (10)|
|lnie||71||887201 856463 868777 873103 875599 (5)|
|satellit||58||879046 828197 893892 (3)|
|fholec||14||893005 892178 893030 (3)|
|lbrabec||11||855824 873065 875599 (3)|
|konrad||6||810040 893699 (2)|
* This is a list of bug reports linked to the wiki results. They don’t have to be reported by that concrete person.
The results are pretty interesting. Bob Lightfoot challenges Andre Robatino’s crown! Together they have more test cases submitted than all the rest of us combined. Huge thanks, Andre and Bob!
I’d also like to specifically thank all community (non Red Hatter) contributors. Besides robatino and boblfoot, namely satellit and konrad have the most results.
Of course, kudos also to anyone else in the matrix. Fedora 18 was a hard and delayed release, and your effort helped us keep its quality up. Especially the new installer interface benefited greatly from lots of testing. Thanks!
If you haven’t participated in Fedora 18 release validation, we would love to see you in the Fedora 19 cycle (the test period will start in a month or so). Follow the announcements, and then please read QA/Join#Release_validation or talk to us in #fedora-qa on IRC.
When reading the statistics, please bear in mind that the numbers are not directly comparable. Different test cases have different complexity. Lots of people test, but they don’t fill in the test case results. Wiki matrices are just a single piece of a large puzzle, people can contribute and test Fedora in a number of other ways, which is not reflected here.
The statistics were generated by the release-test-stats.py script.
If you’ve installed/upgraded to Fedora 18 and you would like to play your media files (music and videos), this is the current way to go:
- Add RPM Fusion repository.
- Install codecs:
$ yum install gstreamer1-libav gstreamer1-plugins-ugly
For some reason the Totem’s auto-search function is now broken, so you have to do it manually. I suspect the reason is that the package names have changed (compared to Fedora 17 and earlier).
Of course all of this only applies to citizens of those countries where software patents are not valid. Otherwise this action would probably be illegal and you might receive a capital punishment or similar.
From Fedora 18, we will finally have LibreOffice included on Live CD, and installed by default! (We were able to do this by raising the Live CD size from 700 MiB to 1 GB, now targeting flash drives instead of CD media). This is great news for our users, because the office suite is needed by many and they had to manually install it in older releases. With this change Fedora 18 makes another step towards reasonable defaults, and it will certainly be appreciated by our newcomers.
Thanks to everyone who supported me in the discussion, and Bill Nottingham for pushing that change.
It’s a bit ironic that Fedora 18 DVD will not install LibreOffice by default, you have to select it as an “add-on” in the installer. The infrastructure standing behind package collections has been re-worked and it doesn’t allow us to enable some collection (like LibreOffice) by default. Of course you can still select it manually. Hopefully we will have it fixed and auto-selected in Fedora 19.
I would like to warn you all about a serious bug discovered in Nautilus in Fedora 17 (GNOME 3.4). If you use it to copy files from your computer to an external HDD, you might experience a data loss (some files missing/corrupted). The problem is that Nautilus doesn’t show notifications properly when you want to eject the drive and all data is not written out yet. The bug has been fixed in Fedora 18 (GNOME 3.6), but it is still present in Fedora 17, and it is reported in bug 886435. It does not affect flash drives, only external HDDs (at least according to my tiny statistical data).
Ideally, it should look like this – if you try to eject the device, you are told that data are still being written: Once that is complete, you are told that you can finally eject the device:
However, none of these notifications are shown in Fedora 17, if you eject the drive using Nautilus. You then assume that everything is OK and disconnect the drive – and some of your data is silently lost.
The workaround is to use GNOME Shell notification area to unplug the drive:
That works well and notifications are shown.
If you happen to use some other desktop environment, like XFCE or MATE or something else with Nautilus, then probably the safest choice it to open up a terminal and run “sync” command. Once it finishes, all your data is written out correctly.
Hope this helps.
After I upgraded to Fedora 18 and I tried to run Google Chrome, I saw this:
$ google-chrome /usr/bin/google-chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory
The solution is simple, just reinstall it (I assume you have google repositories added in the system):
$ yum remove 'google-chrome*' $ yum install google-chrome-stable
It should work now.