incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [RELEASE] Dictionary extensions
Date Sun, 15 Apr 2012 16:14:38 GMT
On Sun, Apr 15, 2012 at 11:49 AM, Andrea Pescetti <> wrote:
> Rob Weir wrote:
>> Let's make sure we agree on what a Release Candidate is.  A RC is a
>> build we (and the IPMC) vote on.  If the vote passes then we release.
>> There are no vetoes in this vote.
> We agree on this.
>> The RC is not the time to start looking for new bugs, or to raise
>> already known bugs.
> Then we have a different understanding of what the target public of a RC is,
> and this is likely due to a difference in processes.

You read what a Release Candidate at Apache is here:

> Historically, produced a numbered Release Candidate
> ( 3.3 had ten, RC1 to RC10) that was made available to the
> community exactly for the purpose of looking for unknown bugs. QA activities
> were planned for the RC phase and, after a few days of availability, a RC
> was approved as final or rejected (and the Release Manager could, and at
> times did, include fixes for previously known bugs that had been
> accumulating and that were significant; none of them was a blocker in
> itself, but each of them would have caused problems to users, so their
> combined effect was blocking the release).

That is what we've been doing with the dev snapsots builds.  Surely
you've seen the QA work Lily has done with testing them?

> Now, if I get it correctly, the target public is just people who have to
> vote on a release and not the community at large, so QA tests are expected
> to be run on an earlier version, or anyway it is not expected that the RC
> phase will be the peak of QA activities. Right? (In other words: the first
> RC in earlier times had a ~80% chance of being rejected; here the first RC
> would have high chances to be approved).

Anyone is welcome to vote on a Release Candidate, but only IPMC votes
are binding.   The RC is not the "peak of QA activities".  All testing
should already be complete as a condition of having a RC.  The RC
would have only limited regression testing, to make sure that any last
minute fixes for release-blockers did not introduce new bugs.

IMHO, the RC should have a high probability of approval from the PPMC,
in terms of product quality and functionality.  We should be proud of
what we've accomplished.  But since this is our first podling release,
there is a chance the IPMC will find some formal defect in the release
(license, notice, packaging, etc.) that could require us to cut a 2nd

>> If you are aware of a bug that must be fixed
>> before we release, then you should have already entered it as a
>> release-blocking issue.  You should not wait for the RC build.
> Everything that is confirmed, P2, a bug, and different from
> 3.3 should either be a blocker or deserve a line in the Release Notes. Do we
> agree on this, or any reasonable tweaking of it?

Nothing is proposed as a release-blocking issue unless the release
blocker flag is set in BZ.  Regressions from 3.3.0 and high priority
bugs are reasonable criteria for proposing a release blocker.  But it
does not become a release blocker unless the flag is set and the issue
is discussed on the list.  That is the process that we've been

See, for example, this post:

> The icon problem falls
> in this case, so I just commented on the relevant thread.


>> So if you think that
>> is a
>> release-blocking issue, then you need to make your case on that now.
> I won't. The effect, as far as the Italian dictionary is concerned, is not
> so big. But then we might discover that, due to that bug, we are bundling
> different versions of the Presentation Minimizer, or any other bundled
> extension, across different operating systems, and the bug might need to be
> re-evaluated.
> Regards,
>  Andrea.

View raw message