Martin Hollmichel's Weblog: Martin Hollmichel's Weblog

The OpenOffice.org Roadmap draw the picture to a more continuous development compared to OOo 2.0. It allows new functionality to be integrated when it is complete. Future 2.x releases will not only be minor bugfix releases but will also contains enhancements on the road to OOo 3.0.
This will benefit both: Developers and Users of OpenOffice.org:

• Developer will be more flexible wrt feature planning: there's no big drama anymore if a new feature will miss a major release deadline, it will be integrated into the code line once it is ready and stable.
• User will sooner get access to feature, he has not to wait for the next major release in every case

Last bot not least there will be less problems with slipping (forward :) ) a major release.

With OpenOffice.org 2.0.1 we have the first new features a micro release. Unfortunately we also got the first problems that we missed the UI Freeze for that feature and missed translation timeline, this result in English string for localized version (see screenshot below) in the main insert menu "Formatting Mark" and it's submenu. Please help fix this issue by providing the translation for your favorite lang into issue 58172 until Monday noon (GMT) for 2.0.1 release.

What's going on in OpenOffice.org development

As you might have already heard, we are still planning for the next releases of OpenOffice.org. Although there is an OOo 3.0 target in the IssueTracker, there is not yet a concrete plan for 3.0. OOo 3.0 currently is the synonym for the next major release of OpenOffice.org.

OOo 2.0 was a major release where we have shrinked down the amount of issues from our original plan to make the release finally happen. For 2.0.1, which is coming soon, we had many items on the list which we didn't managed to do for 2.0. Only few minor new features like "Context menu for numberings" or "Add shortcut to jump to recently used slide and view" will make it into 2.0.1 release.

For OOo 2.0.2 I expect that we will incorporate feedback from 2.0 release to increase the stability further by doing bug fixes. I think we will be able to manage a release about every three to six months, so we're going to plan next releases on this basis. Since we are now able to add new UI into minor releases we can add new features into the product even before the next major release. From my experience in 2.0.1 release, we should have a feature freeze at least 6 weeks before the planned release date, to enable all local communities to do their localization. It's also obvious that this is only doable UI changes or enhancements with a limited amount of strings to be translated.

Changes like bigger UI-changes, enhancement of API's or any other complex changes which needs some more time for implementation and review (rewrite of code, new concepts, major incompatible changes) should be targeted to a next major release.

For this reason I would like to ask OpenOffice.org contributors about their plans for the next time, so that we are able to compile a plan for the time until the next major release. Good starting points for this might be:

• a revisit of the PCD plan of 2.0, what have we accomplished for 2.0, what's left ?
• Publish your plans like Malte already did for performance area.
• Put stalled items like the rewrite of the Chart module onto the agenda.

For 2.0.2, planned for end of February, there are already some interesting items at the horizon, such as the Icon Theme Switching , new implementation of Spellchecking hunspell , Quattro Pro 6 Import Filter for Calc .

Contributing code to the OpenOffice.org repository is not easy, there are a lot of rules to follow. In the past there were again questions about these rules like:

• Have really all child workspaces passed this rules ?
• Do I have to comply with all these rules, I only have just a small change to make ?

We have to keep in mind that we want to achieve to major objectives with these rules:

• keep the quality of the build, meaning we are everytime able to release
• keep integration of new or changed code smooth, don't break the build

Since we introduced these rules we made major steps forward: we now have less build breakages than before and we also experiences less P1 issues when a build has been completed. But we still experience faults when integrating code back to upstream. If we look into these issues, we soon discover two categories: issues which could have been avoided if all rules would have been followed and those, which simply haven't been covered by test cases or where the cost-value ratio is too high. We have now this situation:

• These rules can't ensure that no failures will happen at reasonable cost
• Understanding the objectives of these rules help to avoid integration failures

This leads to the practice that we look at the cost-value ratio for many child workspaces: workspace for enhancing build environment, localization or build fixes will often get a check by code review to get integrated fast, others with feature enhancements will get even more attention by our GateKeeper (Joerg Sievers mark those cws with a pin). I as the Release Manager for the current code line look into many child workspaces and look if a owner of a child workspace needs help or even more control. The good news is that most people involved in this are pretty good in understanding our goals and apply to the rules as needed. If there are questions left please don't hesitate to ask your project leads for guidance or help to get your child workspace finally integrated. So the answer to the two above questions is a "no, but ...".

I updated yesterday the release plan for 2.0.1 and 2.0.2 release ( here ). In comparision to earlier releases the introduction of new features will be allowed. But it should not be expected that now tons of new feature will be available for these releases, only feature with small impact to documentation and locolization are expected. For bigger changes we need a more detailed roadmap which allow coordination among users, development, localizers and documentation people.

It is a good thing to have some paid support for operation the OpenOffice.org website. The site is running quit well since the birth of the project eaxctly 4 years ago. Ok, when got slashdotted, the site was quite slow, but this might not be the failure of infrastructe but the sussess of the OpenOffice.org project.

The collab.net infrastructure offers a framework where the most important stuff for doing software development, SourceControl (cvs), BugTracking and Webcontent, is very convient integrated. People familiar with SourceControl will enjoy the maintaince of WebContent with the help of cvs. Just do your changes with your favorite html editor (vi in my case) and commit it the cvs repository. Page got updated by magic on the site. At least for software developers, providing some "static" documentation or information this works perfect. Almost perfect. From time to time things are failing:

Our community manager, Louis Suarez-Potts, did some update for our birthday page last night and somehow the magic update of the new home page failed (experienced cvs user will see that cvs detected a conflict). Since collab.net provides granted support for the operation of the site, members of the regular OOo community don't have direct access to the infrastructure. This works well for regular problems, but it is a big problem if you want to fix a trivial problem immediately. Like this one.

In an Open Source Project with volunteers all over the world this should not be the problem. The project is working around the clock. In this case we will go the formal way: Write a new issue for this and wait for the resolution of the issue. Things get documented by this proceeding which is important if you several people working on the site. But you loose speed in fixing things, you got dependent on proprietary work of people.

This applies also for related items: Some things, like the cross reference (lxr), CVS Tree Control (bonsai), dynamic web content (php or other scripting), Online Databases (wiki), enhancement of content management services (plone) are available and well accepted in the various Open Source communities but the integration of them into the collab.net infratstructure seems to be a major effort. If we look back the past four years we see lots of minor improvements but the big wish list for the next birthday is always growing. It may be also in real life that the amount of wishes grows with child's lifetime, but from time to time it would be nice to get some wishes realized.

But anyhow, the project has good parents: If the infratructure part is the mother, we can see that the mother will take care of it's child, although her options are limited. The project also has it's thoughtful father: Louis. His community management always gives guidance to the growing child.

Release Notes for the Download are available.

Although the count of open bugs is descreasing, are we ready to release OOo 2.0 begin of next year ?

yes, we will (tell me why) !

some time ago we had some hope to make OOo compile with MS VC Toolkit 2003, which is freely available. This toolkit comes even with the optimizing compiler but some items are missing which are needed to complete a OOo build tool chain.

It just comes with a cl.exe and link.exe, things like a nmake tool are missing. Also in the library section some things are missing: only static C-Runtime libraries are available, the shared one are missing as well as many other libs needed for Win system integration. as a consequence (or vice versa), the same applies for the header files. some of the tools, header files and libraries are available with some versions of free downloadalbe SDKs but's almost impossible to get the complete set of needed thing for free.

The configure switches for all these different flavors of toolkits, sdk's seem unmaintainable for me so I (as well as Volker) will not put more effort into this at this time.

The last weeks I found no time to blog here, I did some training for the Berlin Marathon instead. So a short summary of the training in the last weeks first:

week 10: 53 km
week 9: 18 km
week 8: 78 km
week 7: 70 km
week 6: 78 km
week 5: 80 km
week 4: 79 km
week 3: 70 km
week 2: 56 km
week 1: 9 (+42) km
In the last week before the event during OOoCon, which was an exciting conference, I got only few sleep. woke up 5am on Sunday morning, began to tape my toes to avoid blisters and began other preparations. breakfast at 6.30 although breakfast times usually don't start before 7.30 in the hotel, but they made an exception for the marathon. The OOoCon and my hotel were some distance away from the city of Berlin so I had to leeave some minutes past 7 to get to the start area between Bundeskanzleramt and Reichtag in time. unfortunatly I don't needed to meet with any OOo co-runners so that I could proceed to the start area directly.
temperature at that time was about 9°C and slightly raining. not that comfortable conditions to wait for the start but not bad for running. I started in the last block so that I passed the start actually 20minutes after the starting signal. The first five kilometers through Alt Moabit were very slow because of to much runners. passed km 5 after 29:46, much slower than planned. It was not a good idea to start from the middle of the last block, so there is still not a chance for equable running until Alexanderplatz (km 10, 0:57:33). It became better in Kreuzberg (km 15, 1:24:45) but it was still very crowded until half marathon distance was passed in Schöneberg (1:58:39). so far it was easy running but after passing the "Platz am Wilden Eber" with a exciting atmosphere there my legs became more and more heavy.
from last year I have some difficult experiences to pass the Hohenzollendamm, a long straight 2 km street with only few spectators last year, but this time despite the relative cold weather the spirit was quite good there. so I passed km 30 after 2:49:45, but I had to recognize that a time below 4 hours was hard to achieve.
Now the highlights of the Berlin sightseeing started: Kurfürstendamm at km 33, Potsdamer Platz at km 36 but also the warm up phase ended and the real marathon began and so I also began to slow down a bit. passed the great Gendadamenmarkt at km 38, thought of a big beer at km 39, where I passed the pub where I had some (more) beer on Wednesday with Dan, Michael, Martin, Caolon and others. This really hits me down so that I entered Unter den Linden at km 40 (3:51:58). no more chance to get unter the 4 hours limit so I decided to ignore my pain in the legs and have some more detailed look at Erichs Lampenladen, Neue Wache, Dom, Staatoper, all the people cheering and finally the Brandenburger Tor. It is some of the highlights to pass this famous gate 400m before the finish line which I finally passed after 4:06:02.

here are only less than 11 weeks left to OpenOffice.org conference 2004 and the Berlin Marathon the weekend after it.

Tuesday: 5*1000m (4:14,4:21,4:20,4:19,4:24) (14km)
Wednesday: 90 minutes slow running (13,5km)
Thursday: nothing
Friday: 60 minutes tempo run (12km)
Saturday: 60 minutes bike (20km), met Pavel on irc, slow run 3km
Sunday: 170 minutes jogging (30km), 70 minutes bike (29km)
week total running: ~70 km

Danese had the question : "Do I read correctly that there are nearly 12 million lines of code on OpenOffice.org? That's a WHOLE LOT OF CODE. Is that really correct?"
The simple answer to this question is NO.

StatCVS is simply line counting on the base of the "cvs log" information. This surly gives you a rough estimate and some hints regarding the trend the code is growing, but IMHO it can't be considered as exact measurement.
So StatCVS gives you also a count of lines of comments, empty lines and even more worse, it gives you quite irregular numbers for binary files, e.g. Icon files, OpenOffice documents.
Common understanding is that the measurement of Lines of Code (LOC) is unreliable because it depends on coding style and measurement parameters so comparison of project is almost impossible.

I recently saw on JFree a reference to StatCvs and gave it a try on the OpenOffice.org code base and here is the result:

There are only less than 12 weeks left to OpenOffice.org conference 2004 and the Berlin Marathon the weekend after it.

So I started training for it last week:
Monday: 55 minutes easy running (5km)
Tuesday: 60 tempo run (12 km)
Wednesday: 120 minutes very slow (13,5 km)
Thursday: 3 x 1000m: 4:35, 4:24, 4:31 (9 km)
Friday: nothing
Saturday: 150 min LSD (20,5 km)
Sunday: 120 min (60 minutes very sloooow with my wife, 60 minutes 5:00) (16km)

weeks summary: 80km