Im kind of over gettin told to throw my hands up in the air
So, somewhere between the LibreOffice 4.2.0 and the 4.1.5 release, bugs.freedesktop.org broke through 25.000 reported bugs. A time to throw the hands up in despair? Not at all, as the following chart shows:
- 7% of reports are still unconfirmed or need more information
- 22% are confirmed and unresolved issues, that are not enhancements requests
- 6.5% are unresolved enhancement requests.
On the other hand:
- 33% of all reports have been fixed in some way
- and 30% are invalid or duplicates.
Its interesting to see how now a quarter of the confirmed unresolved reports are asking for new features and enhancements. Its gets even more encouraging, if you take into account that the number of bugs reports is at a long term constant 20-25 reports per day, while over 40% of the bugs intentionally or collaterally fixed changed their state in the last 12 month. So we are picking up speed in triaging and fixing bugs, while the influx of new reports stays constant.
If you are interested, please help QA quite a bit in all this by writing good bug reports, identifying duplicates, confirming new reports, bibisecting regressions, run and test daily builds and prereleases or otherwise helping with the QA Easy Hacks!
It’s so hard when it doesn’t come easy
It’s so hard when it doesn’t come fast
So, LibreOffice 4.2 is released, FOSDEM is over, was very nice and I am back home in Hamburg after a week in London. I missed the LibreOffice UX Hackfest for that, which I heard was also awesome. So without further ado, here are the slides from my quick talk at FOSDEM:
and some errata for it: On slide 13 it says “the same file is also hardlinked from workdir/” — thats not true for quite a while already. LibreOffice keeps around exactly one copy of a library, unlike the confusing three copies that we had in LibreOffice 3.3. This should be a lot less confusing to the curious first time contributor.
Reviewing all these changes in toto, it became how much we simplified getting involved with LibreOffice through this. As the lyrics quoted above say: “Back when we started, we didn’t know how hard it was”.
If there is just one number to take away from all these slides, its that a noop rebuild for LibreOffice on a three year old developer notebook with the distro provided GNU make 3.81 takes just 17 seconds(*). And slide 7 shows still some possibilities to still speed things up beyond that — and while at current speeds it might not be worth it on Linux, it might be worthwhile for e.g. Windows, which is traditionally rather slow when it comes to file I/O.
On a related note, over time we improved the way new contributors can submit their changes on our instance of gerrit in many ways. Thanks a lot to David, Norbert and Robert for the work on this. One only has to look at one of daily digests generated from activity on gerrit and imagine we would still get one mail for each change, update and merge to the mailing list for manual patch tracking as we did in the early days. Thanks a lot also to Mathias Michel for his work on the script!
So if you haven’t done that yet, consider graping an EasyHack and get started!
(*) This includes checking 1.3GB of generated c++ dependency files for some >8000 object files, which we simplify to <350MB.
“Eins, zwei, drei, vier, fuenf, sechs, sieben, acht”
So LibreOffice 4.2.0 release candidate 3 has been tagged yesterday evening. A good time to look back at the cycle and look at some numbers. The number of issues fixed in the 4.2 series are in line with our historic trends:
- 1131 bugs fixed for 4.2.0 beta 1 (at 4.1.0 we had 1045 bugs fixed at that point)
- 48 bugs fixed for 4.2.0 beta 2 (at 4.1.0 we had 76 bugs fixed)
- 67 bugs fixed for 4.2.0 release candidate 1 (at 4.1.0 we had 59 bugs fixed)
- 53 bugs fixed for 4.2.0 release candidate 2 (at 4.1.0 we had 86 bugs fixed)
There is no page for the third release candidate yet, but I assume it to be no exception. Fixing issues is mainly done by development, although QA does the preparation for that by triaging a bug well. But QA also does quite a bit of work before a bug is triaged, and this is not directly locked to changes in code. So I had a look at the numbers simply in the timeframe between the tagging of 4.1.0 rc3 (2013-07-17) and 4.2.0 rc3 (yesterday). In this timeframe, QA did:
- confirm 3114 bugs (change of ever_confirmed).
- resolve 3393 bugs (change of resolution and not unresolved now, this includes the bugs fixed by development).
Naturally, these can not be simply be added up: for example, a bug can be confirmed and then be resolved by fixing it. If all of that happens in the timeframe (as it likely will for a relevant bug), it will appear in all the above counts. Meanwhile, in this timeframe 4092 bugs have been filed by endusers. Of those new bugs filed, 9.3% where enhancement requests. Since not all resolved bugs need to be confirmed (e.g. invalid bugs), these numbers add up nicely.
Speaking of quality, another thing to look at is regressions. How many of those will be fixed in 4.2 as of now? Here is the rundown:
- 1 regression introduced in 3.4 or before
- 2 regressions introduced in 3.5 or before
- 3 regressions introduced in 3.6 or before
- 2 regressions introduced in 4.0 or before
- 8 regressions introduced in 4.1 or before
- 51 regressions introduced on master or found in betas and release candidates
As you can see, most of the regressions fixed with this have actually never been released. This should be encouraging news to those testing daily builds: If you do that, you will be rewarded with quick bug fixes. Still, only fixing 16 regressions that were visible in previous releases seems a rather low count for a release. Well, this is because this count does not count fixed regressions that are also backported to the updates on the 4.1 stable series. As regressions are usually worth that effort, this is usually done unless it is to risky a change for that. If you look for regressions that were fixed in 4.2 and also backported to 4.1, you as of now get a count of:
- 230 regressions fixed in 4.2 that were also backported to the 4.1 series
in addition. See this earlier post for more details on how the backporting works and some numbers on it.
Speaking of regressions, we have a pretty unique tool to corner them: bibisect. How well does this work? I keep tracking these in bugzilla for the last months. Currently 176 bugs have been bibisected, with the number of unresolved bibisected bugs staying constant in the 60-70 range. That is encouraging, as it means that for each regression bibisected, a developer fixes a bibisected regression. This happens currently at a rate of ~2 bugs per week, which is not too bad, as such regressions might be quite hard cornercases that without bibisect would be tricky to pin down. However, only ~14% of our unresolved regressions are bibisected as of now. Clearly, we can improve that ratio with more bibisecting and get more regressions fixed even quicker.
Ok, admittedly, this was a boring and dry post on bug numbers. What can I do to lighten you up? Here is catcontent, presented in LibreOffice Draw 4.2 running on Ubuntu trusty with the awesome new libreoffice-style-sifr icon theme:
tl;dr: We are doing well, but could use even more people testing daily builds and do bibisects.
Sometimes I wonder if the world’s so small,
Can we ever get away from the sprawl?
So these days, most people prefer to use an IDE to navigate their source code. This has often been greeted with some defensive elitism of the “real programmers” kind since the early days of the open sourcing of StarOffice. One does not simply load a code base the size of LibreOffice in your wimpy IDE: while it is possible somehow in the end, its a lot more trouble than its worth to manually set up e.g. all the include path manually to get the fancy stuff like autocompletion. Add to that, that e.g. UNO headers are generated during the build and header were at distributed over multiple IDE unfriendly locations, with many headers even available as copies from multiple locations, before we fixed that.
All these things are fixed now. And while LibreOffice still is a huge beast with our new build system we can get a holistic view of what needs to get build where, how and when. This makes it easy, almost trivial to generate an IDE project file from the build system. And to prove this point, I did just that for the kdevelop IDE. This isnt limited in principle to this one IDE — in fact the kdevelop specific part of this is some 150 lines of Python. So no matter what IDE you use: Eclipse, Netbeans, Anjuta, Visual Studio, Code::Blocks or XCode — you should be able to adapt this. In fact, while writing this, I find there is already work going on for XCode. Feel invited to join the party and make LibreOffice trivially buildable in your favourite IDE!
So as announced to the developer list, this allows you to make navigating, editing, building, testing and running LibreOffice much easier, giving you features like:
- building a module from the IDE
- building all of LibreOffice from the IDE
- nondebug and debug build configs for the above
- starting LibreOffice from the IDE
- running unitchecks, slowchecks and subsequentchecks from the IDE
Dont believe it? Here is a video featuring a stuttering german guy (me) on the audio track showing this:
If you want to show this around on social media, there is also a shorter version featuring the essentials (make sure to link to the HD versions).
A closing note: A long time, common IDEs embrace and extended into the buildsystems so once you used an IDE, you could only use this one IDE and no other. In retrospect, this is obviously doing it wrong. With the current approach, we can make LibreOffice easily buildable in any IDE on any platform. A very important fact for a product available on so many platforms.
addendum: As Karl Fogel wrote “LibreOffice is now ridiculously easy to build.“ before we even had this, it just shows that one can always do better.
He asked me if I’d seen a road with so much dust and sand.
And I said, “Listen, I’ve travelled every road in this here land!”
I’ve been everywhere, man.
I’ve been everywhere, man.
So about a month ago I travelled in one week from Hamburg via Zürich and San Francisco to Oakland and then via San Francisco, Munich and Basel to Freiburg to attend the LibreOffice Hackfest Freiburg 2013 and back to Hamburg. The Freiburg Hackfest is the third and last Hackevent we had in Germany this year (after the Impress Sprint in Dresden and the Hackfest in Hamburg) nicely accompanying the international events like the LibreOffice conference in Milan and our usual presence at FOSDEM.
I have to admit that I arrived at this event with some travel fatigue and some upcoming Ubuflu, so I was not too productive myself, but its good to see fixes like for example in the kde integration (Jan-Marek), in Calc (Eilidh), for enabling bitcoin donations (Florian), to mail merge (again Jan-Marek), to Math (Marcos), for the build system (Michael and David) happening (or at least be prepared at the event). A big “Thank You” to all the angels of the Chaos Computer Club Freiburg that organized the event — when I learned that I would need to travel to the US right before this, I had some doubts if it would result in “remote-organization-troubles” given this was a first time in Freiburg. This was completely unfounded, the support of our hosts was amazing and they seemed to have made a deal with Eris to take revenge for the original snub somewhere else on this weekend.
So, given that I did not do much coding (just some preparation for the KDevelop integration for LibreOffice, more on that later), what can I offer you? Catcontent was not available (no cats at this Hackfest), so I give you the second best thing: the deputy chairman of the board of the Document Foundation patrolling the premises on a skateboard:
So, whats next? FOSDEM! We will of course be there again, and back-to-back with the event we will have a user experience Hackfest in Bruessels. So come and join us:
Take the corner, going to crash
Headlights, head on, headlines
Another junkie lives too fast
Yeah, lives way too fast, fast, fast, woh
So, LibreOffice 4.2.0 alpha1 has been tagged upstream a week ago. It is an alpha release, essentially only a tagged snapshot of the LibreOffice master branch and as such might eat your kitten and kill unsuspecting relatives. On the other hand, if you absolutely are of the type that Metallica roars about in the above quote and therefore you are running the development release of Ubuntu (trusty tahr, which will become Ubuntu 14.04 LTS), you can add the LibreOffice prereleases PPA and try it out and report bugs. Of course, you should not use this in a production environment of any kind!
Im happy to see that this build available again a week earlier than last year, as early testing allows more bugs to be triaged and fixed in time. The more important difference though is that last year, the alpha version was build on the stable and released version of Ubuntu, while this year the version is already build against the early and moving development version of Ubuntu.
We gonna do what they say can’t be done
We’ve got a long way to go and a short time to get there
So, the LibreOffice conference in Milan is just past us and it was awesome — if you missed it, Kohei posted a very nice set of pictures from that event. If you are interested in the talks too, you can find both streams and slides for almost all the talks. One other talk from the conference, I would like to hightlight is Michael Stahls gbuild talk — it was a long journey from when gbuild was still a pet project of mine, but now as the migration is now finished, things unlocked and we (*) are now really reaping what we sowed.
Almost, as e.g. while I was able and eager to send the slides for the lightning talks I moderated, I somehow forgot to do so for my own slides for my talk on tb3. It will hopefully end up on the conference site at some point, but for now I uploaded at at speakerdeck (with the odp originals on the wiki and here):
I didnt bring my own camera and thus missed making pictures during e.g. the lively QA roundtable, but Rob made sure that we get at least some photo on the last day (when many were already on the way home):
So in the next days, I will be hopping over atlantic for a visit to the west coast, just to return to turn “eastbound and down, loaded up and trucking” to be at Freiburg for the Hackfest again. A big Thank You in advance to Tauon and Florian Effenberger, who took over a lot of my organizer duties on this one due to this tight scheduling. Oh, and of course, I hope to see many of you there!
(*) actually they: By far, the most awesome stuff is now done by others than me
I’m easy like Sunday morning
That’s why I’m easy
I’m easy like Sunday morning
So, Ubuntu 13.10 (Saucy Salamander) was released into the wild and comes with a fresh LibreOffice version: 4.1.2. Since the last major version of LibreOffice (4.0) was branched off, 11.034 commits by more than 200 different committers were done upstream up to the release that is now in Ubuntu 13.10. (*) The LibreOffice 4.1 features and fixes page gives an overview what is new with this release: rotating images, embedded fonts, improved interoperability — to name a few.
In the Ubuntu/Debian packaging repository, some 513 commits by 5 authors have been done between the version Ubuntu 13.04 was released with and the just released version. The majority of those commits have been done by Rene Engelhard of Debian. A big “Thank you” for all that work! Now leaving this release behind with a “Girl, Im leaving you tomorrow” on my mind, I am looking forward to what the name for Ubuntu t-series will be, as there does not seem to be an announcement yet (although there have been eager suggestions), start to brace myself for the early cycle madness again and prepare to make sure that Ubuntu t-series will get the best LibreOffice 4.2.
So much for looking backwards. A lot of people are shy and assume they could never be one of the contributors making a dent in LibreOffice, or even get started. Let me show you how wrong that assumption is:
This little chart shows Easy Hacks resolved by newcomers to the project. Easy Hacks are tasks that get need to be done on LibreOffice and can be done without understanding all of the million lines of code and more than 20 years of history — quite a few do not even require C++ skills. They are specifically selected for that — and if you run into any trouble solving those, you can jump in at #libreoffice-dev to get help. So get yourself a LibreOffice build (here’s a video on how easy that is on Ubuntu — with dubstep soundtrack), find yourself an Easy Hack and get going!
(*) I didnt bother to check for the exact number, because checking for duplicates in email addresses is tiresome.
Note: An earlier version of this post talked about 22.000 commits — that was an error on my part fiddling with the scripting late at night.
Go, Greased Lightnin’
You’re burnin’ up the quarter mile
So the conference schedule for the LibreOffice conference in Milan has just been published. The talks, workshops and sessions on the schedule encompass only the so far officially registered sessions. If you have another exciting and urgent topic that you want to share with the others at the conference, you may still get to present a lightning talk in the session on Thursday after lunch!
For that, just send a email to email@example.com right now containing:
- your name
- the title of your talk
- the length/format you want to use:
- freeform 5 minutes (*) lightning talk
- Pecha Kucha talk (20 slides, 20 seconds each = 6 minutes 20 seconds)
Excited to see you all in Milan next week!
(*) changed from 15 minutes earlier as there has been more demand for 5 minutes freeform than for 15 minutes sessions.
I’ve got the power.
So, Im back from vacation. One of the things I did was reorganizing my hardware, and for doing so, I bought a wattmeter to measure what my machines and toys actually consume. A lot of the stuff was what I expected, but there where a few nasty surprises:
| (all values in Watt)
||Ideapad S12||Thinkpad W520||Bertha||TV||Pandaboard ES|
|power supply only||0||0.2||2.5||0.3||0.1|
|desktop w/o display||13||10||122||130||6.1|
From this set a few surprising takeaways:
- The wimpy Ideapad S12 with its Atom CPU eats more power when idling than the Thinkpad W520 with its beefy i7 Quad-Core and 16GB of RAM (13 Watts vs. 10 Watts).
- My TV doing nothing but waiting for the remote to tell it to turn itself on eats more power that each of my notebooks (15 Watts vs. 10/13 Watts).
- Running my desktop (Bertha) as an tinderbox for LibreOffice 24/7 would cost me ~1.000EUR per annum. Doing it with three of those boxes would a very expensive and noisy alternative to what others sell as a room heater.
- My TV eats 30 Watts more when displaying the black screen of a disconnected HDMI signal than with normal TV display. Maybe its expensive to search for a signal?
- Compiling LibreOffice without ccache on my Notebook kicks the power consumption to 90 Watts — but only for a few minutes. Then the thermal controls throttle the machine down to 70 or even 35 Watts, which seems all the machine can disperse over sustained periods.
And then there where these leftover pieces to measure, no surprises there, just a confirmation of my suspicion that the old Asus notebook I run as a home server is eating way too much power:
|(all values in Watt)
||bits and pieces|
|mic preamp off||1.1|
|mic preamp on||10|
|“home server” (decommissioned Asus Z53 notebook)||30|
My tentative conclusions are:
- replacing my old “home server” with something ARM-based like a Raspberry Pi or a Pandaboard breaks even after one year — I should do that.
- Even when under load, a ARM-based Pandaboard has a modest power consumption.
- I will completely turn off my TV on principle as the standby consumption is just pure impudence. As a bonus it prevents my BluRay player from kicking on the 100 Watt TV when I throw in a audio CD (Thanks Panasonic, for providing this excellent and “useful” integration).
- A cheap Netbook might be less powerful, but it hardly consumes less than a high-end Notebook when idling. You get what you pay for.
- I bought a cooler for my Notebook, hoping to unlock it from choking itself with thermal restriction. It should be a good idea in general as the logs not only talked about throttling, but also about more scary MCEs.
- Buying a wattmeter is a good decision, when you run nontrivial amounts of hardware.
Addendum: The 2.5 Watts for Bertha when off may seem bad — but its not at all, if you consider it is running a lights-out management on that.