Get Ready for LibreOffice 3.4

LibreOffice 3.4 is approaching. The second release candidate for 3.4 was released on May 27, and has improvements for Writer, Calc, and much more. Ready for a look?

The upcoming release of LibreOffice 3.4 is slightly overshadowed by the announcement that Oracle is proposing OpenOffice.org as an Apache Incubator project. What does that mean for the free office suite landscape? It's far too soon to tell, though Apache president Jim Jagielski has reached out to The Document Foundation about cooperation. I'm cautiously optimistic that the projects will find a way to work together and benefit the rest of the FOSS community.

But for now, LibreOffice is the only project with an imminent release — so let's take a look at that and what's in store.

LibreOffice is focusing on more modest, time-based releases. This means that 3.4 doesn't have massive new features, but it does have a slew of performance improvements and minor new features that make life a little better. Let's take a look at some of the highlights.

Sadly, the LibreOffice folks still haven't implemented vi-like keybindings for Writer. (OK, that may only be sad for some of us, but still...) But Writer still has a few minor features that you might enjoy.

If you do a lot of footnotes and bullets, you're going to find this release interesting. LibreOffice now has support for Greek (upper and lower case) letters for bullets — not something that I've had call for yet, but might be of interest to some users. (Testing this feature shows that I'm not, in fact, up on my Greek alphabet...) You'll find this in the Options tab of the Bullets and Numbering dialog.

If you're working on a paper or document that will be printed in color, or distributed as a PDF, you now have the option of defining the style and color of footnote separator. You'll find that one in the Footnote tab of the Page Style dialog.

The LibreOffice folks have also been working on "flat ODF" import and export filters — so if you have a need for the .fodt document type, you might want to check this out. What's flat ODF? In a nutshell, it's uncompressed ODF — the standard ODF document is a zipped file with XML data. Most users probably will want to stick with the traditional ODF — but this is a way to use LibreOffice to produce documents that can be worked with by other programs.

The Pivot Table support in Calc has been stepped up a notch in 3.4, and heavy spreadsheet users may want to look at upgrading to 3.4 right away. You now have support for unlimited fields (as opposed to a limit of 8 fields) using Pivot Table. The Pivot Table feature now allows users to define named ranges as a data source as well.

The 3.4 release also adds support for OLE links in Excel documents — so if you're working with a lot of Excel documents, this means that you won't be seeing import errors from Excel docs with OLE links.

A couple of features have been refined to allow per-sheet support as opposed to global document support. Autofilter and named ranges can now be defined on a per-sheet basis rather than being applied to the entire document.

Are you an Ubuntu Unity user? If so, you now have support for the global menu.

The 3.4 release also has a few features for improved graphite font handling, and for drawing text with Cairo as well as improved GTK+ theme support. This means that LibreOffice should look much nicer than 3.3 as a native Linux app.

Do you do presentations, and want to put them up on the Web? (One of the first — and most annoying — questions I get when doing a presentation is "will the slides be online?") This has been, let's say, not one of LibreOffice/OpenOffice.org's strong points. I tried it out with a couple of my old presentations, and it works like a charm now. So if you need to put a presentation online, LibreOffice 3.4 has you covered.

There's also the usual under the hood improvements, bug fixes, and so on. The 3.4 release is not a big leap forward — but it's an improvement and seems stable enough for most users to dive in.

Remember, the LibreOffice project recommends the .0 releases for more adventurous users. If you're wanting to contribute to LibreOffice, or just like to live a bit closer to the edge, the 3.4.0 release is for you. Odds are, if you're reading this article you like to try new features and want to be running the latest and greatest. But if not, then just hang on until the latest LibreOffice turns up in your favorite Linux distribution or at least wait for one of the point releases (like 3.4.1 or 3.4.2) that have cleaned up any nagging bugs that slipped through in 3.4.0.

According to the release notes, you should be able to install 3.4 side-by-side with 3.3. Of course, I read this after I removed the 3.3 packages from Linux Mint and installed 3.4 — but it should save you some trouble if you want to test 3.4 without removing the older release.

Naturally, you'll find packages for most major Linux distributions — the pre-release page has RPM and Debian packages for 32- and 64-bit systems.

The release plan calls for 3.4.1 to be out in late June, and for 3.4.2 to be released in late July. The next major release of LibreOffice is set for next February. Whether the OpenOffice.org news will impact LibreOffice releases, if at all, is unclear. With LibreOffice ramping up, OpenOffice.org apparently moving to the Apache Software Foundation, and Calligra picking up steam, it looks to be an interesting time for free office suites.

Comments (0)
You must be logged in to post a comment. Please register if you do not have an account yet.

View the original article here

Linus Jumps Ahead to 3.0

Last week it looked like we were, finally, going to get a version bump from 2.6 to 2.8. Instead, Linus Torvalds has bitten the bullet and tagged the first release candidate of the next kernel to 3.0.

That's right — it looks like the next kernel release is going to go all the way to 11, er, 3.0. If you missed the discussion last week, this isn't because the kernel is gaining massive new functionality (as it did from the 1.x to 2.0.x series), but because "it will get released close enough to the 20-year mark, which is excuse enough for me." Sounds like a good enough reason here, too.

To be clear, 3.0 will not be a radical change. According to Torvalds, "Sure, we have the usual two thirds driver changes, and a lot of random fixes, but the point is that 3.0 is *just* about renumbering, we are very much *not* doing a KDE-4 or a Gnome-3 here. No breakage, no special scary new features, nothing at all like that. We've been doing time-based releases for many years now, this is in no way about features. If you want an excuse for the renumbering, you really should look at the time-based one ("20 years") instead."
Want to test the new kernel, check for it in the /pub/linux/kernel/v3.0 directory, though the git tree is still linux-2.6.git for now.

If we follow the "once per decade" model, it looks like we'll have Linux 4.0 sometime in 2020.

View the original article here

LibreOffice Progress to 3.4.0

Today we released 3.4.0, there is a great list of new features, specific to LibreOffice available (expertly assembled by Marc Pare and others). Each should also be credited so some of the depth of the (code) developer community is apparent, this is of course in addition to our extensive credits page (kept up to date by a volunteer of course). This is the first major release containing code from many of our new volunteers which is exciting. Of course, there are some great improvements there, I like the named range / data-pilot work that makes it easy to extend the data range you're working on without manually editing perhaps ten data-pilots depending on it but there are a load more. Some of the changes are invisible, and/or behind the scenes - so I thought I'd expand on them here.

The incredible shrinking codebase

First - ridding ourself of sillies - there is lots of good work in this area, eg. big cleanups of dead, and unreachable code, dropping export support from our (deprecated for a decade) binary filters and more. I'd like to highlight one invisible area: icons. Lots of volunteers worked on this, at least: Joseph Powers, Ace Dent, Joachim Tremouroux and Matus Kukan. The problem is that previously OO.o had simply tons of duplication, of icons everywhere: it had around one hundred and fifty (duplicate) 'missing icon' icons as an example. It also duplicated each icon for a 'high contrast' version in each theme (in place of a simple, separate high contrast icon theme), and it also propagated this effective bool highcontrast all across the code bloating things. All of that nonsense is now gone, and we have a great framework for handling eg. low-contrast disabilities consistently. This also reduces run-time memory consumption (we have to cache the .zip theme's directory), and of course binary installation and download size shrinks (we ship several themes to taste) - here is a pretty picture:

The incredible shrinking footprint on Windows

When we first released LibreOffice, in place of the individual install set per language - duplicating the code, artwork, templates, etc. many tens of times on each server we switched to bundling lots of languages (and also the run-time adapted BrOffice branding) into a single package. That shrunk our mirror load from 76Gb down to 11Gb for 3.3, which is now for 3.4 down to 7.6Gb a handy win (of ~70Gb) for mirror admins, making us more agile, and appreciated by our fantastic mirror network I hope. To achieve this, in consultation with the l10n team, Kendy worked hard to split out our help to the wiki - so you can browse it on-line at http://help.libreoffice.org. That of course helps Linux users' space-constrained live-CDs more useful too.
With that work in-place, we managed to cram the top fifty languages into only 225Mb on release, which (sadly) left the remaining languages in a rather larger 265Mb download. In 3.4.0 down to improvements such as the them work above, sharing templates, dropping the BrOffice brand (at the Brazilians request) and more importantly Kami's gret msi packing improvements we've managed to pack all our languages, and many more dictionaries, and more functionality into a single download at 197Mb. That is clearly still too big, but smaller than a MS Office service pack. We are still some 40Mb larger than the original single-lang packaging (which it is our goal to match), but there is plenty more room for improvement (eg. gutting the megabytes of pointless ICU code we ship), and we'd love more help, (cf. scale offset of 150Mb):

Better translation infrastructure

I'm not an expert here, but our fantastic l10n team, swelled to 200 contributors is doing some great work on getting the latest translations into the product. They're using pootle for that, but better (thanks to Andras) we've switched from storing our translations in SDF format, instead using native gettext .po files compiled to various odd other formats during the build. Bjoern has a prototype patch coming to allow run-time .po file translation, to allow post-ship translation and better integration with Launchpad.

Heroic merging

One of the huge, invisible tasks for 3.4.0 was the merging of Oracle's code changes. Luckily, of course we use git - and several split repositories, such that merging should be easy. Then again, we have done lots of widespread changes, many hundreds of thousands, if not millions of lines of diff, stripping dead code, translating thousands of comments, touching every single file, as well as more substantial API and code changes.

One of the things that made the merge more tricky, was that (after decades of inactivity), some Oracle developers decided now (post fork) would be a great time to do some long overdue large-scale code cleanups. One of those was replacing every instance of TRUE with sal_True, same for FALSE, all instances of legacy types like BOOL to sal_Bool, for each of UINT16, ULONG, LONG etc. etc. Unfortunately, not an easy 'sed' either, as witness to some of the bogus "sal_True" type strings that popped out of the works. While a valuable, and much needed cleanup, this results in the kind of multi-million-line patch (touching all the dead code too) that has the effect of obfuscating their other valuable changes, and takes a certain determination to merge and reconcile.

The effort, spearheaded by Norbert with many straight days of mindless grunt work from myself, and able assistance from Thorsten, Kendy, Kohei, Noel and others - hopefully highlights a triumph of determination and survival against the odds, the tedium and some RSI. Unfortunately, due to some comic, transient technical hitches (that resulted in having to do much of the work twice) this merge rather delayed the code freeze and our first betas for 3.4.

Tinderboxes / rapid building & QA

With the rush to get 3.3 out, and the stabilisation releases after it, as well as the one-shot fun of migrating many Linux distributions over to use LibreOffice there was not enough spare bandwidth to get many tinderboxes or build-bots building. Unfortunately, this had quite an impact on the QA teams particularly after the merge completed, which was sad. The good news is, that we have mostly fixed this now, and have much more recent (the aim is daily) install-sets for most platforms available for testing - a great way to get involved is to help with re-testing old bugs against the latest stable releases.

A chunk of this is down to better tooling and scripts to drive tinderboxes, though we still struggle with unreliable Windows builds, cygwin's sh.exe, or perl.exe or dmake like to wedge intermittently some hours into the build. On the Mac front, Norbert had a breakthrough to shrink the build time. An all-lang Mac build used to take 15 hours (13 inside helpcontent2) - he managed to get this down to under 30 minutes using a ramdisk - substantially improving our agility and ability to turn around builds quickly: getting the latest code to QA fast. One of many great build performance improvements - with other much appreciated packaging acceleration wins in the tangle of badly written perl by guys like Jan Darmochwal, Julien Nabet and Steve Butler.

Then of course some QA stars like Rainer, Alex, Cor, Andre and many others have been working hard at finding, cleanly filing, triaging, prioritising and marking bugs, critical work.

Time based releases

One of the key features of LibreOffice, from my perspective, is its time based release process. Italo has done a great write-up with several nice pictures of this, one of these is this:




To me - having a predictable, and time-based release is such a key concept, that shipping 3.4.0 as a carefully labeled, point-zero release on time is more important than shipping an incredibly bug-free product, at a future, undefined point. This avoids a deeply political process of deciding when and if to release, and whose pet bug is worth waiting for and why, and why is his worse than mine, and oh ! I just found another one, lets delay another week. The alternatives to a time based release seem to have lead only to long (multi-month) slips.
Clearly, we have learned a lot this cycle, and improved our processes to make future releases even better. Obviously our succession of point releases: 3.4.1, 3.4.2 etc, will incrementally improve quality: indeed we are confident of that, since we already have a lot of fixes in-place for 3.4.1, however the fact remains that 3.4.0 is buggy (in fact all software is, but it is more so than usual, and we found a lot of bugs rather late). The bright side, is that our future point-zero releases, build on our improved infrastructure will be better in future. This is why we are continuing to advertise 3.3.2 (and the soon to be available 3.3.3) as the primary download build for now (thanks Christian for all your hard Javascripty work to make that fly). Please do - check-out 3.4.0 and get stuck into helping us make the Free Software Office world even more fun, fast-moving, and exciting. A great way to start as a developer is to get stuck into an Easy Hack.

Contributors

Of course, lots of people got stuck in already, and continue to do so. We like to graph statistics of commits by affiliation - charting how many people of what affiliation commit at least one patch per month, that gives us a pretty graph like this:



Which (I hope) shows the strength and diversity of the contribitor base, as well as its extraordinary growth since we launched. Sadly, some like to denigrate and despise contributors that only come up with small changes, personally I started off in Free Software as a contributor like that - and we love to help encourage, and mentor contributors from small things - to greater ones.

Other highlights

Well, of course so many others have been involved in making LibreOffice the success it is today, tirelesss work by many Steering Committee members, like Italo and Florian writing and co-ordinating multiple press briefings concurrently, and many helping translate and promote the software. The design team, being patient as we get the basics right before getting too stuck into fixing the UI (while producing some beautiful, much improved artwork), and no-doubt many others I forgot. And please take note - this is just some of the features you can't see, there are plenty that you can"

View original article here 

Six Months Of Rocking Ubuntu Events

Education and learning has always been an important part of the Ubuntu culture. It is important to us because we always want to present an environment in which everyone is welcome to participate, whatever your skills, location, or experience. We want to make it really easy to get involved in Ubuntu and be a part of the revolution.


Along these lines we always organize online learning events in each cycle that are designed to encourage people to join our community and help get people up to speed with skills and how things work in the interests in growing more and more people who enjoy contributing to Ubuntu and our community.

Today we finalized a stack of dates for the coming cycle and I just wanted share them:

• Ubuntu Developer Week – 11th – 15th July 2011 – a week designed to help up-skill those who want to participate in packaging, bug-fixing and other Ubuntu-related development activities. This is a great week to get started as an Ubuntu developer.
• Ubuntu LoCo Teams Learning Week – 18th – 22nd July 2011 – in this new event we will be providing a set of sessions that are designed to help get LoCo teams up and running and successful. Topics such as how to get members, build an online presence, organize events and more will be here.
• Ubuntu Cloud Days – 25th – 26th July 2011 – Ahmed Kamal will be organizing another set of Ubuntu Cloud tuition sessions that can help get you up and running with an Ubuntu powered Private or Public cloud.
• Ubuntu Global Jam – 2nd – 4th September 2011 – an essential part of the Ubuntu calendar in which LoCo teams around the world organize local events to get together to meet and greet and enjoy contributing to Ubuntu together.
• Ubuntu App Developer Week – 5th – 9th September – a week of tuition sessions about writing apps for the Ubuntu platform and how to get your apps into the Ubuntu Software Center.
• Ubuntu Open Week – 17th – 21st October 2011 – a week designed to be a good first step for brand-new Ubuntu users, deliberately timed the week after release. This is a great first step if you are a brand new user.

Also, many thanks to the new Lernid maintainer, John S. Gruber, for helping to refine and improve the tool that makes these learning events so simple, fun, and enjoyable to participate in.
More about these events as they happen!

View the original article here