LibreOffice rules

I love deadlines. I like the whooshing sound they make as they fly by.

— Douglas Adams

So yesterday was Ubuntu Quantals feature freeze and two important features made it in with the libreoffice-3.6.0~rc4-0ubuntu3 package:

• the awesome work by Antonio Fernandez from Aentos (sponsored by Canonical) on the feature/unitymenus branch
• some PackageKit integration for LibreOffice on Ubuntu (will be upstreamed for 3.7)

I’ll go into the details of both and what they mean for endusers in later blogposts as they each deserving one of their own. Also, for the current stable Ubuntu 12.04 LTS release we have in:

• the LibreOffice PPA a current backport of LibreOffice 3.6.0
• the LibreOffice 3.5 PPA a current update to LibreOffice 3.5.6

This allows users to be up-to-date with LibreOffice on the current stable release of Ubuntu too. Ok, so we are running a tight ship for LibreOffice on Ubuntu, but that is kind of expected, right? Well, yes — but I want to reach out to another point, which is: how we got there. To illustrate that, I want to select some random datapoints on the debian/rules file, which is the core file that makes a package out of a plain upstream build. The situation has improved since the beginning of LibreOffice (LibreOffice-3.3.0-1):

• The debian/rules file, while probably still one of the most “impressive” of all of Ubuntu, shrank by 12% since that first LibreOffice release on Debian and is now at 3173 lines. Removing complexity here is a Good Thing^(tm) and hopefully will continue.
• Less than 3% of the lines are different between Ubuntu and Debian by now in the rules file. That is a Good Thing^(tm). While there certainly are some differences between the distributions, if such vendor changes need modifications in the rules file it is usually a sign of bad design.
• Finally, since that first release, there have been 640 commits made touching that file — 90% of those by Rene Engelhard, 10% by me. In total 1092 lines have been added and 1541 lines have been removed — meaning at least 1/3 of that file has been rewritten. Now, only 1.5 KLOC delta does not sound much, but with a turnaround time of 1.3 days on some architectures even a dedicated machine would not keep up with that for every commit. Also: I bet the rules file of a lot of other Debian/Ubuntu packages will fit in that 1.5 KLOC (or even in the 449 lines we lost since the first release).

Finally, this tasty pie chart shows that the red to yellow upstream parts of the rules file are not that big. Most of the rules file is concerned with mapping the build we want to do to both ./configure switches and dependencies^(*) and splitting up the build result:

This “last mile” of getting LibreOffice on Ubuntu and Debian is often overlooked. I still think it is quite an important (although mostly invisible) job. An explicit “Thank You!” to Rene for all his hard and continuous work on this.

^(*) Yes, LibreOffice has a rule to generate its own control file. Manually maintaining that would be truely painful.

Announcing LibreOffice HardHacks

So when your waiting for the next attack
You’d better stand there’s no turning back

— Iron Maiden, The Trooper

I teased in the last post, that there will be a second important change in LibreOffice QA in this week. Well, here it is: In an combined effort by contributors in QA and development, we will try to improve the way that QA and development interact. The LibreOffice EasyHacks are a well known success story of our project. Now we introduce the LibreOffice HardHacks. When I first threw around that buzzword, one initial reaction by a core developer was:

HardHacks sounds too hard to me. I would be afraid to look at such bugs 🙂

This is what is hiding behind that buzzword:

• The QA team will start in their next call to identify the 5 most critical bugs that need attention. It will repeat that from now on in each of their calls every second week.
  To qualify, these bugs have to be:
  • Among the MAB (most annoying bugs)
  • be triaged as far as possible (e.g. reproduction scenario, version the bug was introduced if it is a regression, best: bibisect for regressions)
  • so they are both important/urgent and well-prepared
• These bugs will be handed over to the core developers
• ESC will try to find a core developer for each bug to look at it and report back in the next week

The aim of this is to keep awareness of these critical bugs high in development and having some kind of qualified feedback in the given timeframe (ideally one week, but at least until the next QA call). “Qualified feedback” might also be: “I still need this information to get forward with this bug.” or “This cannot easily be solved because of foo” giving the QA and the reporter a hint on what is needed to push the issue forward. Hopefully this will prevent that awkward silence on some bugs where everyone thinks its on the other to push this forward and help us collecting all the needed information on the most important and urgent bugs. It will certainly also keep the most pressing quality issues present in the minds of the developers, which might otherwise strive to implement the next shiny and exciting new feature a little too early or too often. Keeping these bugs present will thus also help getting these though solved too.

Lots of bugs around – HardHacks are about those that hardened their chitin armor in unfair ways (source: wikimedia)

As you can see from the comment above these are the bugs that even the core developers have a healthy dose of respect of. But that should not scare you: If you are a developer in the LibreOffice community and already have a few patches for EasyHacks under your belt, feel free to look at the HardHacks too. The core developers will be relieved for any support they can get. Also note that these bugs are really hard nuts to crack, so failure is an option here. However, on the other hand, the benefits of solving the bug are huge: both core developers and QA will be full of utmost respect and gratitude for such an achievement.

The QA team will also try to blog about the results we got for the batch of bugs that were selected — this bit of extra fame is hopefully is another piece of motivation for the developers looking at bugs. Oh, and of course your help in cornering the bugs from both the QA and the development side is most welcome!

On the importance of being a bug confirmer

The truth is rarely pure and never simple.

— Oscar Wilde, The Importance of Being Earnest

Two important things happened in LibreOffice QA this week. The first one has not gone unnoticed by a lot of users: Florian Reisinger closed a lot of old and idle bugs (no activity for more than six month) in state NEEDINFO on our friendly bugzilla. As you can see from this table we have bugs in all kinds of states:

• the “user/reporter states”: NEEDINFO, UNCONFIRMED
• the “bugwrangler states”: NEW, REOPENED
• the “developer states”: ASSIGNED, RESOLVED/WORKSFORME
• the “verifier state”: RESOLVED/FIXED
• the “janitor states”: VERIFIED, CLOSED, RESOLVED with resolutions INVALID, DUPLICATE, WONTFIX, NOTABUG, NOTOURBUG

The lifecycle of a bug ideally makes the bug go through the states UNCONFIRMED -> NEW -> ASSIGNED -> RESOLVED/FIXED -> VERIFIED -> CLOSED quickly. If it gets stuck somewhere, its up to the group named in the quotes to help this move on: For a bug in state NEEDINFO, it is expected from the user/reporter to come up with missing information. For a bug in state UNCONFIRMED, it is needed for somebody (best not the reporter, but a different user) to make sure that the bug is valid. This is not too hard, the details are described on the Bug Triage page on the wiki. LibreOffice is a community project and the best way to get your issues forward is to trade favours: Confirm the bugs of somebody else and let him confirm yours (of course, you should still check if the bugs of the other guy/gal are really valid!).

The bugwranglers then take care to make developers aware of the most important bugs in states NEW, REOPENED according to development capacities. If a bug sticks longer in here, it is usually not the bugwranglers to blame, but the fact that there are just more critical bugs to pipe to the developers at this point in time. However bugwranglers also need to make sure that a bug has all the important information on the bug before it gets to development. For example, when it is a regression: what was the first version that misbehaved, stacktraces, test case, test documents. If there are multiple bugs which are about the same severity to choose from to hint development at and one has all that information while others do not — QA will tend to go with the ones with most information on them.

The job of the bugwranglers is to find those bugs that stick out (Photo: Jessica Lucia, Creative Commons license)

The developers then crunch their heads on trying to solve these issues. And if they need a break and some cheering up, they will look at a WORKSFORME bug that seems to have been fixed to QA/users, but nobody claimed to have done that intentionally. If they can see that the bug was indeed solved, the bug can move to CLOSED/FIXED.  The latter is not a high priority task at all though.

If a bug is set to RESOLVED/FIXED by a developer, the fix can be verified by pretty much anyone on a daily build: while the developers are usually trustworthy folks, it does not hurt to check. A very good side effect of this is, once the daily build is installed, one can easily torture it a bit and see if the trustworthy folks of the last sentence recently broke something in a horrible way: If so they should get notice ASAP via a new bug report.

The janitor states are mostly dead: We then consider that bug finished. Now some bugs were reported more than a year ago, when the freedesktop bugzilla did not yet have a UNCONFIRMED default state — those were moved from NEW to NEEDINFO as they still needed confirmation. If no other user confirmed your bug since then and there was no activity on the bug for more than half a year, the bug would now have been moved to RESOLVED/INVALID with Florians cleanup. In such cases, find somebody to confirm that what you describe is indeed a bug and ask him to reopen that bug for you. Note you dont need to wear a QA uniform, QA hat and badges to do so, although you might earn them by doing Good Work(tm). The QA team is looking for more hands and you can best find us on the QA mailing list or on IRC and other means. Another good way to get started are the QA EasyHacks.

Oh, the second important thing happening in QA this week? Its still work in progress and this post was long enough, so I will do a post on its own about it. The buzzword will be: LibreOffice HardHacks.