Mittwoch Jan 19, 2011

some changes for the 3.4 release process

The current release of 3.3 and earlier release has shown that there is some room for improvement. For delivering a release in time it is important for the release management to be able to track the release relevant issues, for product management and marketing it is useful to know what will get into the next release. For both objectives we used so far the target milestone field in the IssueTracker.

This worked not very well for product management because there were frequent re-targeting actions in front of releases of hundreds of issues as well as there are many issues getting the release target at the time of implementing/fixing/QAing. In summary we can say the release target milestone was a good indicator for the upcoming release but nothing we can call reliable. Also many issues got their target milestone at the time of finishing the implementation short before integration into the code line.

For the release management the scenario can be described in a similar way: Many of the release relevant issues got the right target milestone in time, but this required in most cases the manual review of experienced QA or DEV folks and too many issues showed up very late or often too late (in the rc phase) in the release process although they got reported in time.

For the upcoming 3.4 release I would like to change the bug handling to come to more satisfying results for both: Release Management and Product management/product development and as well to a better transparency for all participated people in the community.

Let me start with Product management/development related items first:

  • For a feature driven release model the current practiced target milestone handling makes perfect sense. But since we had a time driven release model in the past and we also want to stick with this model there will be no more setting of the target milestone for features, enhancement and “usual bugfixes”. The planning of new features needs to be done without the target milestone field of the IssueTracker. I will it leave to the project leads on how they want to deal with the planning of new stuff for their product. I think we all would like to see in the end something like a roadmap for the single projects and the overall project.

    Of course IssueTracker will still be used to track the issues integrated for a release, meaning we will provide an automatism to set the target milestone at the time of integration into the actual code line.

        If wanted, you may stick the the “.x” target for issues that are on the roadmap (e.g. 3.x)

  • We have lots of issues nobody works on or even intends to work on (e.g. see all the issues with target OOoLater which have been untouched for years). Usually these issues shouldn't have an owner assigned or should be in the status STARTED, it is recommended to set the owner “unassigned” and set the status NEW so that it will be transparent for product management and all other users that these issues are orphaned. This might also encourage people to grab those issues and work on them. This also reduce the amount of “My Issues” in your personal intray and helps to stay focused.

With these two actions, setting the target milestone not before the time of integration and usage of the unassigned owner for orphaned issues, we achieve better transparency. And it forces the projects members to prioritize open issues for the coming releases and to make realistic assignments. But the more important issue is, to get the release done in time. For this we need to determine the release relevant issues:

  • Definition of release relevant issue will be as follows:

    • P1 issues

    • keyword data_loss set and Prio is P2, P3 or P4

    • keyword regression has been set and Prio is P2 or P3

    • keyword usability or accessibility and Prio 2

    • keyword release_blocker (to be confirmed by release blocker status meeting)

    • privacy, security or legal issues

    • release related TASKs (increase version numbers, urls, those tasks should have subject "Release 4.5: <do this and that ...>" those issues are required to get fixed (meaning integrated) until the milestone after the next milestone.

    • A release relevant issue may be deferred to the next release if effort or risk estimation doesn't allow a fix in a reasonable time frame and has been qualified no to be a release_blocker.

    Please understand this list of criteria as a starting point which can be changed and adopted by the release status meeting, your feedback is appreciated. Also the lists of issues which are currently matching these criteria may need to get reviewed and adopted in keywords and Priorities. This should also encourage all people to set the right keywords.

    Such as release relevant qualified issues have the next release target.

Being able to track the release relevant issues and make the fixing of the issues a priority enables us to move many fixes we are currently doing in the rc-phase to an earlier phase in the release process. We currently do have a quite a bunch of issues fulfilling the criteria of being release relevant but to ensure that these issues get reviewed and resolved soon I will do the release branch after we reached an acceptable amount of issues.

This results in the following plan for upcoming 3.4 release:

    • until Jan. 27th : review and understand these guidelines, remove 3.4 target from open FEATURES, ENHANCEMENTs and non release relevant issues.

    • Until Feb. 14th : finish your 3.4 planned features, enhancements, this is the planned UI(Feature freeze date. The current data in EIS ( show that most of the now planned cws will be finished by end of January/Begin of February, so integration until Feb. 14th looks reasonable. The Feb. 14th release status meeting we will review the

      • OOo 3.4 feature status: Are all required features / UI changes in actual codeline integrated ? Do we possibly need to extend the UI/Feature Freeze code line ?

      • OOo 3.4 defect status: Do we have less than 25 release relevant open defects ? If yes, we're ready to branch off the 3.4 release code line and provide a Beta 1 build. If not, we will:

        • provide a Alpha 1 build with the current status

        • if feature status has been declared as closed, no more integration of non release relevant child work spaces is allowed

    • the Feb. 14th release criteria meeting will be re-iterated every 3 weeks until branch-off criteria a fulfilled. Release next Alpha <n> build after that timeframe.

    • Also after branch-off has been executed, the Beta builds will be done with a three week integration until the amount of release relevant issues smaller than 3 (yes, it should be zero) , than time for release candidate one has been reached.

    • For translation there will be almost no change in the process, it just may be that we fulfill the rc criteria before the last translation changes.

For the than following 3.5 development code line the fixing of release relevant issues should have more priority than non-release relevant changes, this will ensure shorter stabilization phases for releases. Especially if also the the continuous l10n project (see for details) get established, we get into the situation that we will be able to do releases with much shorter stabilization phases. 3.4 release changes

Dienstag Nov 16, 2010 Hackfest in Hamburg Hackfest in Hamburg, 

starting Friday evening in Schachcafe with good food and beer, continued on Saturday and Sunday in the rooms of the attraktor e.V. , thanks to them for providing this great facility. Also the Pizza services was a good one, I never saw that big pizza boxes before.

Pizza boxes

On Saturday we started at 11am with an introduction round, some new face were there, around 24 people in total. Eike gave an introduction into the build environment, in parallel Ingrid and Regina already started hacking Chart.  I left a little early in the afternoon but the amount of pizza boxes I discovered on Snday morning this has been a long night. We continued at noon with a wrap up what has been done the last day:

  • Knut reported about scripting in Lisp
  • Ingrid about new features in chart and on how to deal with new features in ODF
  • Fridrich about his regression testing for the WordPerfect filter
  • and Björn about the new Gnumake buildsystem for
Finally the hackfest was finished around 3pm and agreed we should continue that on regular basis, eventually we will continue with a bugfest early next year at the same location.

Mittwoch Sep 01, 2010 3.3

People wondered why there is no release date defined in For the past releases there was a detailed, complete release plan including date for all details in advance. That schedule is important for involved people (like l10n, qa and marketing folks) to plan their resources for the release and make the release process transparent for all.

With the current release we did not enter all concrete release details in this plan. In the past those dates were not that reliable, we missed schedules in the translation area, we missed schedules with frequent release candidates and due to miscellaneous other problems. Because of that we are now entering the date for the next upcoming milestones we know for sure but not for all dates in the future. As the release process is in general defined all participants are able to do the time estimation for their slots after the start of the release process, meaning the branch off of the code line.

Continue making the release date public although we know that there is a high probability that we miss the date is setting the wrong expectations to the public. And we continue to get reactions again like: "The release is delayed again."

The release status meeting stay responsible for the release coordination, so if there are questions or concerns please don't hesitate to show up there.

Montag Jul 26, 2010 canery ?!

Google now found a "new" distribution mode for their chromium development builds: parallel installation of frequent developer snapshot. Something now has some years: Developer snapshots. Can be installed in parallel side by side the regular release. So nothing to improve for ? I think there are some things to improve the Developer Snapshots we have now:

  1. Improve the name: Find a more attractive name for OOo-Dev ( Developer snapshots). Seagull distribution or so.
  2. Improve the advertising: OOo-Dev build or not unstable just because they are Developer snapshot. I'm using those builds since years, they may have some new bugs, but I never lost any data by using OOo-Dev builds. We should be brave and promote our weekly builds more prominently.
  3. Make quality a priority for OOo-Dev builds. Meaning not to wait or take some time to fix any reported regressions before the next release but already for the next (OOo-Dev) build.

Montag Mrz 29, 2010 Product Development ?!

How important is Product Development (PD) for ? PD is about doing the right things to make an product successful in the market. In 2004 the marketing project worked on a strategic marketing plan. It was written in front of the 2.0 release. This plan covered the time until now and by reviewing the plan what was achieved in the last years a gap between plan and reality will be discovered. Not a real surprise but surely a fact that should be reviewed and discussed.

We should have three product development representatives in the Community Council (see community council charter). With the resignation of John McCreesh we will loose an important driver of the Product Development. I would like to see a review of result of the marketing plan wrt the past five years before John leaves. Not that the Council should be driver of Product Development but we need a re-initiation of this effort.

The only candidate now for the non-code contributing projects for the next round of council elections will be Thorsten Behrens; he's a well known great supporter of the hacker driven "Product Development", from my perspective a good representative of the code contributors. But not for the non-code contributing PD projects of OOo as the charter of the CC states. It's difficult to do a "no" vote against the only candidate for this seat, especially if the candidate does good things for the project and I consider him as a good friend of mine. But we need a general review of the PD part of the project, and therefore I want to see a person representing the classical school of product development and call for a no-vote and call for new candidates.

Samstag Mrz 27, 2010

New BuildBox up and running

A new buildbox for has been set up and is running.

On the 8-way Linux host there are now 2 virtual Windows machines up and running. All prerequisites for building on Windows are already installed and the machines are ready to build cws. I'm looking now for people volunteering testing this.

I will add another Windows instance beginning next week and prepare this as an addtional Windows buildbot/tinderbox. But maybe also another volunteer would like to set this thing up ?

Please feel free to contact me for getting access to one of these boxes.

Dienstag Nov 10, 2009

Orvieto ESC meeting now in transition to distributed source code control (mercurial)

The transition of the source code repository from CVS via subversion to mercurial is now almost complete. It was a long way to go, there was the agreement for a long time that an migration from CVS to a more modern source code control is desired. The major obstacle was the lack of native merge capability support, simulating the merge tracking with supplemental scripting was not that handy and snappy as it should be. Also more and more people expressed their desire for a modern distributed SCM which had much more better merge support at that time. At that time of discussing all the reviewed distributed systems (git, mercurial, bazaar) were still at heavy development so that we decided to do step in between: to change to subversion as it also seems to be the perfect step in between for the data and history migration. Unfortunately we found out quite late, the the subversion merge tracking was far from being mature so that we still suffered performance issues with that system.

mercurial logo git logobzr logo

We than had a deeper look at the latest developments of git, mercurial (and partially bazaar) and found that both systems seem to fulfill requirements. Within the ESC the discussion about the pro's were done passionately, "unfortunately" there were no serious cons (beside bzr at that time) so that the discussion look like a vi vs. emacs war, but of course we need to have just one system in the end. So finally, Thorsten and Michael M. made clear during the meeting that there were disappointed about the final outcome but again there was an agreement that mercurial will able to do the job.

ODF Icons

 We also had a brief discussion about a new proposal of ODF Document Icons:

goal is to connect the artists of the various teams (Gnome, KDE, StarOffice, etc.) to get a common look and feel for these icons and take care of the different themes and color schemes of the various desktops at the same time (see also here for earlier proposals)

greetings from Orvieto,

Dienstag Sep 01, 2009

On our way to 3.2

A lot of stuff is going on for 3.2 release. What are your favorites ?

 I'm sorry that I not listed all contributions to being done during the last month. For a full list of contribution please visit  and do your favorite query.

Dienstag Mai 05, 2009

Open Minds ?

Recently I had to make a tough decision for the upcoming 3.1 release. A blog entry claiming that rules are not followed triggered the following explanation. I really appreciate all the feedback and sometime also the criticism within the release status meeting. Fridrich, you have been and are invited in that meeting on regular basis. With your particpation we could have avoided an offensive sounding blog one can't comment on the site.

While the release candidate 1 went out a security issue was raised in the bugtracking system. Members of the community already observed for longer time the efforts to do an update of the very old version of python (2.3.x) to a recent version. Since this update was driven by a member of the community (Joerg) in his spare time the progress was not that fast as desired but work was ongoing.

At the time I got noticed about the reported security issues I already knew that that we need to do a second release candidate and asked some of my Sun colleagues if we can do anything to help Joerg to get the update done so that the issues is resolved. The policy established by the security team was that we try to address any security issue before the final rc actually is in the process of being released.

So we started help working on the child workspace (mainly the support of Mac, Solaris and Windows platform, the work for Linux, BSD was almost done) did QA and the tinderboxes run and finally decided that the cws was ready to integrate before the next release so that we complied with all the rules of development. Although I have to admit that this was a tough decision because exchanging code of that size always is with some remaining risk. Knowing that in only very limited usage of python code is there and we are confident that this code was covered during QA I finally decided to nominate this community owned cws before the last release candidate.

Sonntag Mrz 15, 2009

Continuous Integration, an alternative for ?

Some time ago I stumbled across an article about continuous integration ( and that this now had become a mainstream technique for software development. Been there, done that was the first thought. In ancient times of development we already had that model: we maintained a single source repository and everyone commits every day. The result was not as good as desired. During heavy refactoring of the code for new big features we ran regularly in the situation that the active development code line was broken. Broken means the source code built fine but the product itself had major bugs that made QA difficult or impossible. That why the concept of child workspaces has been invented (also know as private workspace, private system build and private versioning in SCM pattern language ( ). With this concept we were able to do complex feature development on private branch and keeping it in sync with the latest changes on the development codeline. There we some child workspaces living for three years before finally integrated, e.g. aw024, aw033).

But although in child workspaces verifications builds and automated tests are done there are still bugs which will be found by manual testing. One have too find the balance between running (and extend the test cases) the test suite for longer time and integrate early into the development code line to enable a broader group of testers for giving feedback.

current integration model

With the current integration model we're doing 0.5 up to 3 builds a week. So isn't this already something like continuous integration ? There's one problem with it: In theory, once you have updated your branch (cws) to the HEAD of the development codeline there are no conflicts to resolve when merging then those changes back, it would be possible to automate this step. Since a build for all the languages and platforms will typically last more than 1 day it has become practice that a whole bunch of cws get integrated before the next full build is started. Thankfully the Release Engineering takes care of the integrations then by sequentializing them and coordinate with the developers about potential conflict resolution. This leads to the situation that it can take several days the a build of the integrated child workspace finally is available. I'm not sure if this is a problem at all but I started to wonder about drawing a picture that would like more continuous integration.

I finally got this picture:

sequential integration

The assumption in this picture is that it is possible to do a minimal verifications of the build significantly faster than within a day, e.g. by reducing the build configuration, less languages, less platforms, reduced feature set. If it would be possible to do several builds a day in this way, this would be the possibility to resync their branch to the latest know buildable HEAD of the development codeline. Integration in to HEAD and also the revert back in case of breaking the stuff should then be doable by pure machine power without human interaction. Once a day a farm of build machines would be able to provide a nightly build which could be the basis for manual and automated testing:

nightly builds

I'm not sure if this picture make a big difference and if it is practical at all. At least this would look like more continuous integration, I'm interested in how about others think about it.

Donnerstag Mrz 12, 2009 Engineering Steering Committee has met

Earlier this week there was again a meeting of the Engineering Steering Committee . Most interesting discussion was about the upcoming move to a distributed sourcecode configuration management (SCM) tool. Since the past transition from CVS to subversion it turned out that the new merge tracking feature introduced with subversion 1.5 works not that well as expected we now want to hurry to do the final move to a system which is doing the merge tracking very well. We know that modern distributed SCM like bazaar, git and mercurial are able to do this very well. Unfortunately bzr was not able to do an import of the existing (already down-strapped history) svn repository so that Heiner's evaluation covered git and mercurial. It confirmed my observations that it almost an equal race between both. Like vi vs. emacs. We expect that both will do their job. Unless nothing surprising will reveal in the OOo DSCM survey I think I will support to start pilot by using mercurial. Why ? Other big projects (sponsored by Sun) like OpenJDK, OpenSolaris and Kenai also do use mercurial. The upcoming release 3.1 already got a delay caused by the move from CVS to subversion, I don't want to do the 3.2 release based on subversion again, we need to start work on the transition to a DSCM now so don't expect me to do long discussion about some feature details of git vs. hg.

A happy vi user :-)

Mittwoch Mrz 11, 2009

Getting a minimal workenvironment for CWS handling at (Part 2)

There was an interesting posting from Thorsten Bosbach some time ago about setting up a minimal work environment.

In the meantime the configure scripts moved from the subdirectory config_office to the root of the source tree, so some minor adoptions need to be done for getting the minimal work environment set up again. Since in subversion there in no chance anymore to have single file under revision control we need to use the "svn export" workaround to get the new top level configure scripts. For a detailed list of files needed to set up the environment please have a look into my script for automating this.

The configure script is designed to set up the build environment of all the stuff needed for generated to complete product and not all of these settings a currently switchable by the configure script. For Unix, the X11 Development Header (and libraries) still needed to be installed, including such libs as freetype. But if these are available, just the Archive::Zip modules for perl is needed at the moment. For Windows, the situation is worse. There are many prerequisites, e.g. msi tools, macro assembler, platform SDK and many more, which can't be disabled by configure at the moment, so a minimal set up of the build environment is difficult to achieve.

Since the bash now have a new >>& redirection operator, which appends the standard output and standard error to the named file and also the parser now understands `|&' as a synonym for `2>&1 |', which redirects the standard error for a command through a pipe we really should use bash as the default shell to make the "--with-use-shell=bash" switch obsolete.

No surprise, this minimal build environment can't only be used for the testautomation module, but also for all the dictionaries provided as extensions (svn co svn://; cd dictionaries; build) and the extras modules (example documents and templates).

Donnerstag Jun 26, 2008

I will win Wimbledon !

When watching a tennis match together with members of my tennis team, it is often fun to comment on the match, comment on mistakes of the players and what have could have done better to win the point. So it will not take that long until somebody says that if you really play as good in practice as you're able in theory, you will win even the Wimbledon championship ! Everybody who ever saw my tennis play in practice is pretty sure that I will never win any championship.
But why I'm telling such a simple story ? I was wondering for quite some time why some people are very shy to do many of their technical discussion open in the public. So far I have heard the answer, that doing work in small, closed teams is much more effective than doing this is big team. And I wasn't able to prove the opposite. The story of commenting a tennis match gave me finally an idea for the reason: Just commenting a match has almost no effect. I'm not the person on the playground being responsible for the result of the match. Although my comments and advises are correct, I am finally not able to give the right response because 1) I'm not the player and 2) even if I would be the player, I would not be able to give the right answers - in practice, because I have not the power or the resources for the right answers. Even worse, if I would hear in that situation some comments on how to give better answers, this would make my play worse because I would get angry about these "advices". Even if these advises are correct and given with the best wishes for me, they will be destructive for my play.
I guess the same applies for some of the related discussion on, people don't want to hear any advise if the originator of that advise does not have the power to help with the appropriate action.
So my lessons learned are:
  • I only will participate in discussions where I'm ready to help in an active manner, if I'm only able to give an advise without sustaining help, I will shut up. I will assume that the actors also have read the right books and doing the right things that there are able to do.
  • I will do as much discussion as possible do in the public, but I will use also as much filtering as I can for those people which are generating noise without really providing help, but I will carefully listening to people which are 'literally' helpful.
  • A person who is "responsible" (in German "verantwortlich", not "zustaendig" how many Germans are sometimes misinterpreting the term "responsibility") for something should be able to give answers to any (maybe silly) question, if a person being in charge of a certain project will act in a closed environment, he will never be able to be responsible !

So in short:
  • Be open, otherwise you will not be able to get new, unexpected help and you will never be responsible for your project !
  • Only give advise if you are able to help !

Mittwoch Jun 11, 2008 PDF Import

A first developer snapshot of the PDF-Import Extension is now available on the Extensions Website.
Imported a couple of PDF files laying around on my disk. I'm quite surprised how many authors seen to think that PDF can't be edited anymore. Using the security settings (restrict permission) should help to set the expectations right.
Also new with the PDF Import extension for is the possibility to create hybrid files (PDF containing ODF). This allows the editing of those document with the original document format.

Mittwoch Sep 12, 2007 Writer vs. Word 2007 on slashdot

On Slashdot some comments based on the review by Bruce Byfield of

Martin Hollmichel


« Juli 2016