>OpenOffice 3.0 NOT in intrepid

>This post really isn’t about OpenOffice (but the bug report is here, Subscribe if you want OO3 in Intrepid or think Ubuntu should have included it. Please don’t add comments)

This post is about one of the ideas I wrote down for the future of Ubuntu, that I wrote down as part of my application for Ubuntu membership.

This is what I wrote:

When starting a new release.. let’s say 9.04 the Jolly Jacana, branch the code you are going to end up shipping. So if it’s going to include Firefox 3.1, switch to a Firefox 3.1 nightly ASAP in the dev process. Try to match what that project does itself. Nightly builds for Firefox, Every two weeks or so for OpenOffice, etc.

Yes, releases can slip, but another point here is, we should include the latest that we think we can ship, first. We can always fall back to the previous release, if it slips to far.

We should never wait for an official release of core desktop software in an alpha, it is so much better to include rcs, beta, alpha, or even nightlies that way we can provide the upstream with what I’m pretty sure is the largest linux based testing ground for that software.

Comments? Questions? Concerns? Thanks for reading.

Note: I didn’t guess the 9.04 release name correctly 🙁

11 thoughts on “>OpenOffice 3.0 NOT in intrepid”

  1. >This is a good idea for two reasons – as you say, the feedback heading upstream is good. However, I think that the potential for quickly getting patches and co-operation from upstream is also a lot better. It would pull Ubuntu a lot more into their processes. And at least ensure the final releases get debs, too. 🙂

  2. >This is exactly what Ubuntu does. Firefox 3 was included in Hardy way before it was released, GNOME 2.23 was in Intrepid as soon as the first ‘alphas’ appeared, ditto for kernel 2.6.27. OO.o 3 wasn’t the goal for Intrepid, so no OO.o 3 pre-released went into it.

  3. >OOo was considered too, but the chance that its release date would slip was too high. Perhaps 2 versions could be tested in parrallel so that later it can be decided which to use, but that would mean some more work (although ooo3 was already being packaged now too by the ubuntu devs in PPA).

  4. >Actually Shot, for everything except the main section, Ubuntu syncs from Debian sid. It could quite easily get closer to the upstream by taking select packages from Debian Experimental and working with the Debian developers to stabilise them, at least at the start of the cycle. MOTU on steroids, if you will

  5. >sounds good. it works well with gnome dev versions in ubuntu.

    you say it is easy to back out if the final release of OOo (or whatever) slips. currently i am not sure if it is. i have seen packages with versions like foo-2.0-ubuntu1+really-1.8.1, where a crazy version is needed so that apt things the old stable one is newer than the dev one.

    maybe apt needs some work to make it easier to back out mistakes.

  6. >In the case of OO.o, openoffice.org3* packages couldn’t have been tested in parallel with the 2.4 version (check the relevant parts of the discussion in Launchpad).

    Backing out of the upgrade by creating 3.0.1~really2.4.1 versions would ugly and actually nigh impossible, due to the number of the related packages and the various dependencies between them.

    As much as I wish to have OO.o 3 in Intrepid by default, I fully understand the decision to stick to 2.4.1 and provide 3 in intrepid-backports and/or PPAs.

  7. >So pretty much what they did with Mozilla Firefox 3.0 and Ubuntu Hardy; They released it as 3.0 Beta 5. I have NO idea why they didn’t do this for OpenOffice.org 3.0, none at all, ESPECIALLY because it was a RC much earlier than Firefox was a beta.

Leave a Reply

Your email address will not be published. Required fields are marked *