Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jogischmidt@googlemail.com
 designates 209.85.214.47 as permitted sender)
Message-ID: <5024BFE9.50109@googlemail.com>
Date: Fri, 10 Aug 2012 10:01:45 +0200
From: =?ISO-8859-1?Q?J=FCrgen_Schmidt?= <jogischmidt@googlemail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE][3.4.1]: current status update
References: <50229A36.80107@googlemail.com>
 <20120808180921.12e3a9cbd2458920803d306f@iol.ie>
 <AE9AF2D651BA49C584091F4551F4A0C0@googlmail.com>
 <20120809143914.GA24341@localhost>
In-Reply-To: <20120809143914.GA24341@localhost>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

On 8/9/12 4:39 PM, Ariel Constenla-Haile wrote:
> Hi J�rgen,
> 
> On Thu, Aug 09, 2012 at 01:33:29PM +0200, J�rgen Schmidt wrote:
>> I would like to propose now a new snapshot build based  revision
>> 1371068 (tel:1371068).  
> 
> -1
> 
> Didn't the last build show us that it is really a bad idea to propose
> one build just because there is a fix for a release blocker? Browse the
> archive looking for the rev. number to get a timeline idea:
> 
> 1367440
> 1367911
> 1368799
> 1368968
> 1369110
> 1369843
> 
> A small resume: Rob's finding the missing update setting, Josef finding
> two issues on Sunday, even before the RC was announced on Monday; a new
> RC for those two fixes on Tuesday; now there is a fix, so yet another
> RC... What if another release blockers are found tomorrow? Yet another
> RC on Friday if the fix is available?

First of all I already mentioned that I would change some things when I
again would act as release manager. I would indeed expand the timeframes
between more official snapshot builds. But not only this.

We did official snapshots over some weeks and it seems that these
snapshot were not tested very well. Some of the issue were there and
were already in 3.4.

Some of the issues were of course introduced by other fixes that were
not tested careful enough. But that happened and everybody can try to
improve the own work to reduce such things. But more important is that
we improve the communication and coordinate the testing efforts better.

I was also not very happy this time and I already mentioned that I
wanted too much. But we agreed more or less on a release date end of
July. And it looked not bad, all critical and marked blocker issues were
fixed. And I simply tried to bring the release out, failed and learned
my lesson ;-)

Some of the issues who resulted in a new snapshot had nothing to do with
the office but more with pro-active actions towards graduation.


> 
> In the meantime, I propose
> 
> https://issues.apache.org/ooo/show_bug.cgi?id=120518
> https://issues.apache.org/ooo/show_bug.cgi?id=120389
> 
> Crash bug 120389 has been reported on 2012-07-27, nobody notice it until
> the user made some noise. This shows that something is really not
> working with the way RC are proposed right after a fix is found for
> a release blocker, IMHO there should be enough time (a week, for
> example) to test the RC, even if a release blocker is detected, because
> nothing prevent this from finding another release blocker.
> 

I wouldn't have requested a new build when I would have seen this issues
before.
The bad things here is that we haven't noticed this critical issue for
10 days which is of course not good. But everybody who noticed such
things can raise the fingers and can point others to such things.

We should now really focus to fix the problems and bring 3.4.1 on the
road as soon as possible.

After the release is in front of the next release and we can reflect
what went wrong or not so good and what can we improve and how.

One thing is very clear we need working build bots. To reduce the
workload for those who do the builds and make it more independent from
single persons. And to provide regular builds for continuous testing and
verifying.

Juergen