Brno will host LibreOffice Conference 2016!

1 Comment

So I can finally share publicly that Brno will host LibreOffice Conference 2016. After GUADEC 2013 and Akademy 2014, it’s the third major desktop conference that will take place in Brno. The venue will be the campus of Faculty of Information Technologies of Brno University of Technology which is one of the major computer science universities in the country with a lot of open source participation. That’s also where GUADEC 2013 and 2015 took place.

I was one of the initiators, but most of the work done on the bid was done by Jaroslav Řezník and OpenAlt group which will also provide the event organization with a legal entity.

The conference will take place in the second week of September, looking forward to meeting everyone interested in the open source office suit in Brno!

How ABRT helped us make Fedora Workstation more stable

Leave a comment

Last week, the official Fedora Project account asked users on social networks why Fedora is their distribution of choice. Probably the most frequent answer was that Fedora is THE GNOME distro, that it has the best supported GNOME, which really made me happy, but what made me even happier was that I found a lot of answers like “You won’t believe it, but I use Fedora for stability”. Indeed, the stability of Fedora has improved a lot since I started using it, especially in the last releases. How did we achieve it?

There are several reasons why Fedora is more stable than ever before. What plays an important role is that the significant changes have settled. GNOME 3 matures, the wild beginnings of systemd are also over, Anaconda has stabilized a lot, too. Another reasons is the Fedora QA team, which now has 10 people who test Fedora full time. This is something no other community can enjoy. If you add volunteers and the fact that the team uses more and more of automated testing, you get a lot of test coverage. What I think has also helped is focus. We created three official editions – Workstation, Server, Cloud and defined what MUST be good (the three editions) and what CAN be good (everything else – spins, labs,…). We have also changed the strategy. Fedora is supposed to be progressive, but it doesn’t mean we need to force immature features on users. However, we also doesn’t want to be too conservative and become another Debian. I think we have found a good balance. The strategy is to have stable defaults and experimental features as opt-ins that are just a few clicks away for early adopters who would like to test them (this strategy was used for DNF, and now we’re using it for Wayland). This way, Fedora is stable enough for users who just want to use it, and still fun for those who like living on the edge of future technology.

However, today I’d like to focus on a different factor behind improved stability of Fedora – ABRT, which stands for Automatic Bug Reporting Tool. It’s a tool that helps users report software problems. One of the main problems in software development is to get reports that are detailed enough so that the problem can be identified and fixed. If the report states: “I clicked a button and the window disappeared”, it doesn’t help you find the problem and it most likely won’t get fixed. But if the user attaches a backtrace and a set of relevant logs, the chances go up sharply. That was the first milestone for ABRT – to collect all relevant data in the system and help the user report it.

But the results was bugzilla flooded with ABRT reports. Developers simply didn’t have capacity to go through them and analyze them. They usually ended up filtering ABRT reports out. That was why ABRT went on to another milestone – to create statistics that would help maintainers identify which bugs affect a lot of users (and thus should be fixed) and which are just corner cases. And this finally made ABRT a very interesting aid for developers.

The statistics can be found on Retrace Server. They provide a lot of information. Not only can you find out how many crashes the bug is responsible for, which is the most important information for prioritization, but you can also learn in which release of Fedora, on which architecture etc. What is also very useful is that ABRT can group crashes together based on similarity. Then you can find out that, for instance, crashes in ten different components are caused by a bug in a single library these components are using. The number of reports in bugzilla has decreased significantly, too, because ABRT started identifying duplicates and creating reports only when enough info is collected.


Stats of a problem.

The desktop team started using ABRT roughly a year and half ago. Developers are told to check the stats if their components pop up in the chart of most frequent crashes. I regularly check it, too. And if I find something my team is responsible for, I notify the responsible developer about it. But it’s been quite boring lately. If you check stats from stable releases, you won’t find desktop components so easily. And ff you do find something from the desktop after all, it’s usually already marked as fixed.

But it was not always like this. Fedora is primarily a desktop distribution, so desktop components are heavily used and they were high on the list of most frequent crashes. But ABRT enabled us to prioritize and focus on the most frequent crashes. And you can see the difference in the real-life usage. I rarely experience a crash in GNOME or default Workstation applications.

After good experience with ABRT in GNOME, I also advised KDE maintainers in my team to use it to prioritize. When they went through the list, they found Plasma crashes that had an origin lower in the stack (X11 or drivers), so not easily fixable for them, but they also found quite a few trivial oneliners which affected thousands of users. The ABRT stats are also used by some of our partners. I know Intel uses them to monitor problems in their video driver (btw kernel is associated with most of the frequent problems, but in this case, the problems are not crashes, but rather kernel module oops which users don’t even notice). CentOS started using ABRT, too. That’s helpful if you want to identify frequent crashes in RHEL because if it crashes in CentOS, it most likely crashes in RHEL as well.

ABRT is also useful for users. Not only can it collect relevant information about a crash for you, and make it much easier to report it in bugzilla, but if you don’t want to deal with any bug reporting, you can at least let it send microreports which build the statistics. By doing so, you let us know that the crash that could be fully reported by someone else affects you, too. You can even go for silent microreporting which doesn’t disturb you at all. That’s what I turn on on computers of average users. They will never report a single problem themselves, but by sending microreports they still contribute to quality of Fedora.

I also use ABRT to report problems in software that is not part of Fedora repositories. ABRT collects info about a crash for me and I can pick what I need from it or send it to developers as a whole package.

ABRT has really significantly contributed to quality of Fedora, at least in the desktop part. Kudos to all who have worked on the project for that!

Fedora Group Chat on Telegram

Leave a comment

I created a Telegram group chat for Flock 2015 and it turned out to be very popular. Around 70 people joined the chat which is half the attendance of the conference. It was also pretty useful, some found an adapter to borrow, some found a ride back to Boston etc.

When Flock was over, I was going to delete the group chat, but some people suggested that we could keep it as a general chat for Fedora users and I was like “why not”. So if you’re using Telegram and want to chat with other fellow Fedorians, join

Where is Fedora Magazine most popular?


Matthew’s keynote at Flock 2015 contained a lot of data about the status of Fedora. One of the stats that caught my attention was what countries draw the highest number of views at Fedora Magazine. There are not many surprises. The United States are leading by a large margin. Big countries such as Germany, UK, India, Brazil follow. The Czech Republic is on the 14th position which is not bad because it’s difficult for such a small country to compete with giants in absolute numbers.  But the chart looks very different if you sort countries by views per capita (number of views per one million citizens):


Now, the Czech Republic is leading, followed by Sweden, the Netherlands, and Switzerland. I’m glad to see FM so popular in our country. We try to link to it as much as possible on and promote it elsewhere. It seems to pay off.

I’m going to GUADEC and Flock!

Leave a comment

Tomorrow, I’m traveling to GUADEC 2015 which is held in Göteborg, Sweden. It’s going to be my 4th GUADEC and the location is kinda special to me. When I was a kid and was a lot into football, my most favorite goalkeeper was Thomas Ravelli who played for IFK Göteborg which thus became my favorite foreign football club. I was in Göteborg five years ago and it was indeed a beautiful city, but I didn’t manage to purchase an IFK jersey. So hopefully, I’ll have an opportunity this time.

I’m also very much looking forward to the weather because the weather forecast for Göteborg is 18-20C while temperatures in Brno are getting back over 35C. We’re having the hottest summer all my family relatives remember. We might get more than 30 tropical days (30C and more) this year, so the cold Swedish climate will be a nice retreat from the heat.

But I’m primarily looking forward to the conference itself. The schedule doesn’t look too busy, but I’ve still found a lot of interesting talks and some hard collisions of areas of my interest. I will surely attend talks by Caolan and Stephan from my team. And I’m glad there are actually quite a few talks on LibreOffice.

BTW I’ve also created a group chat in Telegram for the conference (you can join it by following At this year’s Akademy, they used it as the official means of communication and they found it very useful and popular. Open source conferences traditionally use IRC channels, but at conferences you get disconnected and connected very often and that’s not where IRC excels. Moreover a group chat in Telegram can be hooked with an IRC channel via a bot. I most likely won’t have time to set up the bot, but if someone wants to volunteer…

The annual conference for Fedora contributors – Flock – is very close after GUADEC this year. I won’t even have time to travel back home, so I’m flying to Rochester, NY directly from Göteborg. I will have two talks there (both on the same day, it actually be the first time in my life I have two talks on the same day). One is on the long-awaited transition from FAmSCo to FOSCo/CommOps and the other on Fedora SWAG. I’d like to conduct it rather as a discussion than a typical talk because both topics have a lot to discuss.

I’ve also created a group chat in Telegram for Flock. To join, just follow I, Kushal Das, and Dennis Gilmore used it to communicate at FUDCon APAC and found it very useful, so why not to include more people?

After Flock, I’m taking a week off to travel around the East Coast to see old friends, do some shopping etc. I also hope finally go to Quebec City which I’ve always wanted to visit.

Most popular web browsers among Fedora users


Google Chrome is the most popular browser in the world. It is so popular that some call it a new Internet Explorer. But that’s based on global stats. In Red Hat, I’m responsible for web browsers, so I wondered what are the most popular web browsers among Fedora users. So I asked through Fedora accounts on Facebook and Google+: “Which browser do you use the most in Fedora?”

I didn’t look for exact numbers. It’s clear that such polls can’t be 100% representative and for instance Google+ users have inclination to use Google products which can be seen on the comparison of results from Facebook and Google+. However, I think the results give you a rough idea of what browsers are popular among Fedora users. And the results are:

fedora-browsersThe surveys differed a bit. G+ supports polls, but only up to five options. So I pre-selected five browsers I expected would be most popular, and told the users to write a browser of their choice to comments if it’s not among pre-selected options. Facebook natively doesn’t support polls, so users wrote their preferences in comments. Even though other browsers were not discriminated by not being pre-selected the results were very similar. None of them got more votes than any of the pre-selected five. The total amount of votes on Facebook was considerable lower than on Google+ (1262). And the findings?

  • Firefox and Chrome/Chromium are the only relevant browsers among Fedora users. They take up to 95% of the pie. Opera and Epiphany were a bit more popular among Fedora users on Facebook, but neither of them exceeded 5%. All other browsers got just a couple of votes: Midori, Konqueror, SeaMonkey, Pale Moon, Vivaldi, Lynx,…
  • Firefox was the winner, a pretty clear one on Facebook and a close one on Google+ (49% vs 48%). Firefox is the default browser, so it’s not surprising.
  • What really surprised me is the huge difference between Chrome and Chromium. I thought there would be more people who prefer open source solutions, but apparently a lot more people prefer convenience even among Fedora users. You can find Chromium in alternative repos and it’s easy to install, but it doesn’t include Flash player and other closed source goodies. With Chrome, you get it all with an installation of one package. In terms of numbers of users, Chromium is pretty much irrelevant if you compare it to Chrome.
  • Quite a few people said that they were primarily using Firefox, but they had Chrome for Flash. When Flash goes finally away, Chrome will lose one of its significant advantages.
  • Opera used to have a market share of ~10% among Linux users. In this survey, it got 4.9% (FB) and 1.7% (G+). It took them more one year to release the new generation of Opera (based on Chromium) for Linux after they discontinued the original Opera (12.16). Apparently most users left and never came back (I’m one of them).

Growth of Fedora Repository Has Almost Stalled


I went across statistics from Fedora Package Database and what caught my attention is that the increase of number of packages in the official Fedora repository has almost stalled:

fedora-number-of-packagesThe number of packages in Fedora 22 is 17021 and is not going much since Fedora 20. Does it mean there are no more projects worth packaging? I don’t think so. The number of open source projects goes up like never before, just look at GitHub.

I think this trend is related to the growth of Copr. The number of projects has been rising exponentially there. Mirek Suchý reported a couple of months ago that the number of projects in Copr was almost 3000 and almost 2000 were active. And the numbers have increased significantly since then.

It’s actually a success. It means we have achieved what we outlined in the Fedora.Next plans: we’ve built a ring of software around Fedora which has low barriers to entry for packagers and where software is easy to install for users. Although the number of packages in the official repositories is not growing like in the past the total amount of software available to Fedora users has grown like never before. That’s great.

What we’re still failing at a bit is how to build on this and bring the best of Copr to official Fedora repositories and convert the most promising Copr packagers into Fedora packagers. The official repositories still have their relevance. The quality of packages there is significantly higher than in Copr. We should encourage Copr packagers to work on their packages to meet Fedora standards and become Fedora packagers. We should show them the path. I can imagine that we offer an option in Copr to run the source packages against fedora-review to give the packager a hint what needs to be done to meet the official repository standards and if he/she is interested we can point him/her to documentation for the rest of the process.

The current situation is a great opportunity if we streamline the path to quality. Then Copr can serve as a broad source of “playground” software from which useful and proven projects can get deserved quality of integration and make it to the official repositories. But it’s also a threat because if we don’t provide a path and encourage Copr packagers they may just be satisfied with the easy way to make and maintain packages in Copr and no one will want to package software for the official repositories any more.

Older Entries


Get every new post delivered to your Inbox.

Join 34 other followers