incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: [RELEASE][3.4.1]: current status update
Date Fri, 10 Aug 2012 16:52:38 GMT
On Fri, Aug 10, 2012 at 1:01 AM, Jürgen Schmidt

> 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 ;-)

Juergen --

In my opinion, you are doing a great job as release manager. And yes, you
are correct  that some of these misfires were caused by inadequate testing
of preliminary 3.4.1 releases starting  from at least a month ago. As we
went along and I looked at the weekly reports that were supplied by QA, I
didn't feel the fixes warranted an additional download, and so I did
nothing. Maybe others felt the same, and we didn't do enough testing.
Consequently, some issues were evident until very late -- a week or so ago.

I appreciate your perspectives on all of this. We do need to put more
effort into diligent testing AND communication.

> 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
> >
> >
> >
> >
> > 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


"Never express yourself more clearly than you are able to think."
Niels Bohr

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message