I, Bjoern Michaelsen, apply for upload rights for package(s) LibreOffice.

Who I am

I was working as a fulltime developer on OpenOffice.org since 2008 for Sun/Oracle in the writer framework team. Since February 2011, I am working at Canonical and take part in LibreOffice development.

I am also a member of the LibreOffice Engineering Steering Committee from its first announcement and an elected Deputy Director of the Board at the Document Foundation. Im also a certified LibreOffice developer and a member of the certification committee

My Ubuntu story

As a firm believer in open source, I want to strengthen the position of LibreOffice on the Linux desktop. Ubuntu is simply the best general propose linux desktop available right now and I am excited to be part of that. I have been a Linux user since 2002 mostly on gentoo and Ubuntu.

I am essentially solely responsible for LibreOffice packaging on Ubuntu for Natty, Oneiric, Precise, Quantal and am working on Raring right now.

AFAIK, I am currently also the only Ubuntu guy having commit access to the Ubuntu/Debian LibreOffice packaging repository at http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=summary -- Rene Engelhard, the Debian maintainer, is the other and main commiter there.

My involvement

Examples of my work / Things I'm proud of

Back at Oracle I reworked the build system of OpenOffice.org. Over the last 2 years LibreOffice migrated to this build system on a module-by-module basis. The new build system removes a lot of old cruft and simplifies things like porting to new platforms. LibreOffice is using the new build system and we are profiting greatly from its use.

Directly on Ubuntu I worked on getting the transition from OpenOffice.org to LibreOffice done on the Natty release and was the maintainer for LibreOffice ever since. I also helped working on the lo-menubar integrating LibreOffice into Unity and the worked on the functionality replacing lo-menubar in Quantal by having the functionality directly in LibreOffice. This was upstreamed for LibreOffice 4.0.

Over the year 2012, I helped kickstarting the QA team at upstream LibreOffice with leading conference calls every second week. LibreOffice QA seems to be self-sufficient by now (2013), and I hope I can delegate more and more of that responsibility.

I created bibisect -- one git repository with 262 completed Ubuntu builds covering a range of 26000 commits/18 months of LibreOffice that helps hunting down regressions. The effort has been enthusiatically received upstream at LibreOffice an is being integrated now in the daily builds/tinderboxes.

I lead the initiative to introduce structured code review for LibreOffice. This in production now for manual review with more than 1500 proposed changes handled and will be integrated with tinderboxes real soon (so that you can upload a patch, and get it build and tested on all platforms before it hits the master branch).

I am usually working on multiple machines. I have a:

• Thinkpad W520 that:
  • runs a local jenkins instance which:
    • create source-tarballs
    • create source-packages in pbuilder
    • build binaries a pbuilder
    • in separated jobs for each series
  • has VMs to get packages smoketested there before uploading to a PPA

• development and patch generation (upstream and package changes) usually are done on a different (faster) machine: http://skyfromme.wordpress.com/2012/11/12/dicke-bertha-online/

In a ideal case, I perform SRU release testing as follows:

• local building and testing of prereleases

• once rc2 is tagged upstream, it is build in a "hidden" PPA and then copied over to the LibreOffice PPA (this is roughly one week before upstream final)

• one week after upstream tags rc2 as final (and after two days of staged testing in the PPA, I submit the package for SRU, if there are no known problems)

Prelease updates in the same major are done in a comparable fashion, but timeframes might be squeezed to meet deadlines.

The first upload of a new major is a very tricky business -- to complex to be discussed here. To further improve the quality of LibreOffice packages, CI is key: For now that is:

• getting stuff early into PPAs for broad testing
• bibisect (which allows early testing of prerelease master)
• a well working upstream QA
• upstream gerrit integration with tinderboxes and test suites on the tinderboxes

I also for LibreOffice 4.0/Raring started packaging the stuff needed for running the 'subsequenttests' (a set of integration tests), so that they can be run against the installed packages. Currently subsequenttest are run during the packagebuilds 'make check'. As there is an effort to move the tests slowly to cppunit unittests and away from integration test (to allow closer feedback loops for devs working upstream on the product), in the long run it might be needed to also run these unittests against installed packages (and not only during the build).

Somewhere along the way, I also rewrote the get-orig-source rule for LibreOffice (when Debian/Ubuntu moved from the old go-oo wrapped build to a native one), which is not trivial as LibreOffice is essentially a distro of its own containing the tarballs of external projects/packages (e.g. libcmis) which can be build as part of LibreOffice or as a separate package. To generate the tarball of these tarballs essentially a 'fake build' has to be started. This work is also at upstream Debian now.

Areas of work

• LibreOffice packaging

• LibreOffice related packaging

• LibreOffice upstream development

• Ubuntu desktop team

Things I could do better

Learn more about how packaging is done 'properly' for packages not as specialized as LibreOffice. Unfortunately, LibreOffice leaves me no time for that right now.

Plans for the future

https://blueprints.launchpad.net/~bjoern-michaelsen

General

What I like least in Ubuntu

Bug 1 is not fixed yet.

Comments

If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.

Endorsements

As a sponsor, just copy the template below, fill it out and add it to this section.

Martin Pitt

I have been mentoring Bjoern since he joined Ubuntu development in February, and have uploaded most (all?) of his OO.o/LibO uploads since then. I was truly impressed how fast he managed to understand the very complex packaging, and he quickly picked up the usual packaging tools/procedures. He also managed to fix nontrivial bugs in the supporting packages around LibO, such as spell checkers, hyphenation, etc. I trust him to upload libreoffice and -l10n himself now, and to ask about new scenarious/problems he does not know about yet.

Thanks Bjoern!

-- pitti 2011-05-02 14:29:56

(entry written by Bjoern): Rene Engelhard (asked on IRC)

I asked Rene Engelhard (Debian maintainer for LibreOffice on IRC) about an endorsement. His reply (in german) was essentially: "Are you kidding?" because I was the guy doing the Ubuntu stuff for the last two years.

-- bjoern-michaelsen 2013-01-07 12:30:57

Sebastien Bacher

Bjoern has been working on the Ubuntu libreoffice packaging for a while, I've been mentoring his uploads for some months, and can confirm he's doing solid work there. During this time he showed a good understanding of the Ubuntu packaging work and the Ubuntu cycle and processes (dealing with SRUs and security updates as well). He's also managing good interaction with Debian, and of course with the upstream community. I would trust if for upload rights for libreoffice.

Didier Roche

Bjoern is the closer maintainer to libreoffice build system that we can ever get I've been mentoring some of his uploads and he progressed more and more up to the point that I'm confident that he's totally able to deal with all libreoffice updates alone nowadays. I completely +1 him for having upload rights on libreoffice.

TEMPLATE

== <SPONSORS NAME> ==
=== General feedback ===
## Please fill us in on your shared experience. (How many packages did you sponsor? How would you judge the quality? How would you describe the improvements? Do you trust the applicant?)

=== Specific Experiences of working together ===
''Please add good examples of your work together, but also cases that could have handled better.''
=== Areas of Improvement ===

CategoryPerPackageUploaderApplication