LibreOffice 4.0 alpha1 has been silently tagged in the LibreOffice repositories three days ago. Yesterday, I uploaded a build of it for Ubuntu Quantal to the libreoffice-prereleases PPA. Its a pre-release, an alpha — essentially just a named daily build — and will kill your dog and eat your children. Also, it will not cleanly install yet without removing your old version of LibreOffice first. But it has lots of nasty new features and tasty new bugs. So if you are a bug hunter and want to help to make the version of LibreOffice in Ubuntu Raring the best ever, this is your chance to test and tease this version and get it the most polished one ever in a Ubuntu release. Happy testing and bug reporting!
P.S.: At just three weeks after the UDS this is likely the earliest date of making available the upcoming LibreOffice version for the upcoming Ubuntu release. I am looking forward for this to pay off in less bugs even more stability of LibreOffice upon Ubuntu release.
Oh Lord, won’t you buy me a Mercedes Benz ? My friends all drive Porsches, I must make amends.
— Janis Joplin, Mercedes-Benz
So one cycle is over, UDS is done, blueprints are mangled — so far nothing different for me from anyone else working on Ubuntu around this time. Ah, but then there is one more thing that is special for a LibreOffice maintainer: new hardware. Shortly before UDS I consider updating my hardware for the next cycle. This time, I did — here is my new baby:
Although I name my machines usually after the element of having the same proton number as the last part of the local IP, this time it was different: She already had a name, before I even could make up my mind about IPs: Bastian and Claus from picom, who went though some extra trouble to build this beast, affectionately and unofficially called her “Big Bertha” — presumably a historical reference. Given that this “desktop” with 32 cores and 32GB RAM builds LibreOffice in 18 minutes flat (or 3 minutes 20 seconds with a warm ccache), I could not help but to keep that name.
In total this gives me this as workhorses:
left: Thinkpad W520 — i7-27020QM with 16GB RAM (once called ‘mobile buildserver’ by my colleagues at Canonical)
center: Sun X7197A screen and a Unicomp Customizer keyboard for Big Bertha
also center: Nexus 7 (running Ubuntu), Galaxy SII (running Android), trusty old Casio CFX-9850GB plus
right: Ideapad S12
The Casio is clearly the weakest computer of those, but still is more powerful than the first one I ever owned. And finally, next to the table:
below the printer: my old IBM x3800 that I would fire up for emergency extra compile power or when it was getting too cold in the room (now decommissioned by Big Bertha, and on sale at ebay)
behind the printer: old Asus Z53 running fileserver duties
in front of the printer: original IBM Model M, for backup if the Unicomp should fail me
the trusty old Sun Ultra 24, now replaced by Big Bertha (so decommissioned, and already sold)
Not in picture: A few routers and two Pandaboards. I guess I used up all my showboating credits for a few years now and promise to keep silent for a while on this.
Dr. Soran: What if I told you I found a new truth?
Picard: The nexus?
— Star Trek: Generations
So UDS is over and you can find the results of what was discussed there showing up bit by bit on my blueprints this week. Some highlights:
Ubuntu will extend its daily testbuilds (plus testsuite runs) to three scenarios:
Running a master build with mostly LibreOffice internal library versions
Running a release build with mostly system libraries
Running a QEMU ARM release build
The first is intended to find upstream bugs and regressions and I intend to have it integrated it with the set of other upstream tinderboxes churning away at constantly building and testing LibreOffice. The second is more important to find regressions in the system libraries that LibreOffice depends on — as the release branch should be free of build or test failures in general given the review requirements for pushing to it. So it will test for stuff outside of LibreOffice breaking LibreOffice (like lp#1017125 or lp#745836) on Ubuntu. The third will hopefully improve the visibility of bugs in the ARM build.
Speaking of ARM: Ubuntu is easily installable on an Nexus 7 and I had to try it out obviously. Not only Ubuntu also LibreOffice is running quite nicely on it as you can see in this video (note that I even opened the document template twice in my inability to use a mouse — I prefer keyboards):
Link: LibreOffice on Ubuntu Nexus 7 and a Model M
Other stuff discussed at the UDS: Some boring packaging detail, fixing up the upstream packaging with the hope of getting more logic directly into upstream instead of fixing around it in our ./debian/rules. We also had a discussion on bibisect and if it can be applied to Ubuntu as a whole — discovering some overlap with http://snapshot.debian.org/ — still bibisect might be something to consider for example for GNOME.
I also learned that https://errors.ubuntu.com/ is shaping up nicely, and expect that to become even more awesome combined with phased updates — esp. for LibreOffice.
Its been a while since the LibreOffice QA team started to look for HardHacks and give them to the LibreOffice development team for their kind evaluation. While the HardHacks idea is not yet 100 days in office, it is a good idea to look how they turn out and especially give kudos to those who dared and succeeded in tackling these terrifying beasts. Here are the HardHack solvers:
It is very encouraging to see so many volunteers involved in fixing these bugs — dispelling the myth that fixes for such hard nuts to crack cannot possibly be provided by a community. Kudos to all of those who gnarled away one or more of these and a special thanks to the volunteers!
Apart from the development side, there is the bugwrangling side too: Making a good HardHack isnt easy either — it often takes some good bug triage instinct and skills to get all the information needed to have a good report for development. Luckily, there are some who are great at that kind of work too — here are the top bugwranglers in October 2012:
315 bug contributions: Roman Einsle
300 bug contributions: Rainer Bielefeld
161 bug contributions: Julien Nabet
139 bug contributions: Joel Madero
109 bug contributions: bfoman
67 bug contributions: Korrawit Pruegsanusak
54 bug contributions: Alex Thurgood
47 bug contributions: Markus Mohrhard, Michael Meeks
36 bug contributions: Hashem Masoud, Michael Stahl
23 bug contributions: Lionel Elie Mamane, Urmas D.
22 bug contributions: Horst Kaleski
20 bug contributions: Jean-Baptiste Faure
19 bug contributions: firstname.lastname@example.org
18 bug contributions: Uwe Altmann, Andras Timar
16 bug contributions: Regina Henschel
15 bug contributions: Cor Nouws
13 bug contributions: email@example.com
11 bug contributions: Rob Snelders
10 bug contributions: Ivan Timofeev
All in all, LibreOffice is proceeding nicely in doing away with the huge heritage of old bugs: Right now, over 58% off all bugs filed on the LibreOffice bugtracker are already resolved (*). As Florian Effenberger said at the LibreOffice conference: We have only just begin!
You are of course invited to join the developers fixing the HardHacks or the the bugwranglers helping us pinning them down for the developers. Especially, getting started in bugwrangling is easy!
(*) ignoring feature requests
UPDATE: Kohei is such a humble and honest man — he just notified me that I should read fdo#48366 and recheck whom to credit for it: Its really Markus Mohrhard, so one more fix in that provided by unaffiliated volunteer (moving Markus up to position two in that list too).