openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer <>
Subject Re: Be careful before the release
Date Mon, 24 Mar 2014 10:26:17 GMT
On 24.03.2014 10:22, Herbert Duerr wrote:
> We're on a good way to a healthy AOO 4.1 release so we should avoid 
> the pitfalls that prevented a timely AOO 4.1 Beta release.
> Let's examine this negative example a bit further, so we can all learn 
> from it: A commit [1] stopped the Beta and forced the only respin that 
> was needed despite the massive changes+improvements that went into the 
> code base.
> [1]
> The commit broke the installation of language packs and this breakage 
> wasn't discussed before. The responsible developer sneaked that 
> train-wreck in with a mega-patch under a non-suspicious comment. I 
> don't remember him discussing the breakage of language packs before 
> and that the creation of patches could negatively influences the 
> usability of the language packs wasn't discussed either.

I was the one who caused this build breaker and I am sorry for it. It 
was not the first and will not be the last build breaker that I 
introduced.  I did not announce it in advance, because -- maybe this is 
hard to believe -- I did not do it on purpose.  I also don't have a 
crystal ball that let's me see my future errors.  Otherwise all my code 
changes would be error free, which, sadly, they are not.  It was an 
honest mistake in a very complex feature (enabling our build system to 
create patches).  I made the error in a file that was directly linked to 
the new feature.  I did not see, at the time, that it would affect the 
regular build.

> Of course one could say "It happens", but since that developer gets 
> VERY annoying if "It happens" to anyone else the same casual attitude 
> would be inappropriate.
> What's worse is that the commit comment [2] for unbreaking the 
> language packs was "Wrong initialization of ." which is completely 
> unusable. It didn't even mention language packs. That they were broken 
> and now they are fixed. And what's that '.' Is this some magic 
> hyper-linked dot? We should better use commit messages that can stand 
> on their own.

You are absolutely right.  As an explanation, but not as excuse: what 
happend with this particular comment is, if I recall correctly, that I 
accidentally hit RETURN in mid-sentence.  And then I was too lazy to 
look up SVN documentation and find out how to fix the comment.   Instead 
I relied on all the necessary information being present in the issue 
description (for example see and provided 
the correct comment in the issue 
(  I had the 
chance to fix the broken comment when I merged the change into trunk.  
But that seemed to me to be a bit dishonest, like I where trying to 
cover up a mistake.

> [2]
> So in short: Be careful, be professional, don't do unto others what 
> you wouldn't want them do unto you, and yes "It happens" and we have 
> to deal with it. Positively if possible that is.

I am not exactly sure what that is supposed to mean.  If you have a 
problem with anything I have done, except from the build breaker, please 
be more explicit.

I just have one wish.  I don't have a problem with my errors being 
pointed out in the public.  After more than a decade as developer in an 
open source project I have grown a thick skin.  But please don't do that 
to others.  That might discourage potential developers from joining our 


> Herbert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message