Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A84A5983B for ; Wed, 18 Apr 2012 21:01:15 +0000 (UTC) Received: (qmail 1361 invoked by uid 500); 18 Apr 2012 21:01:15 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 1261 invoked by uid 500); 18 Apr 2012 21:01:15 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 1252 invoked by uid 99); 18 Apr 2012 21:01:15 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Apr 2012 21:01:15 +0000 Received: from localhost (HELO mail-vb0-f47.google.com) (127.0.0.1) (smtp-auth username robweir, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Apr 2012 21:01:15 +0000 Received: by vbbfr13 with SMTP id fr13so5780271vbb.6 for ; Wed, 18 Apr 2012 14:01:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.116.20 with SMTP id k20mr2113822vcq.54.1334782874061; Wed, 18 Apr 2012 14:01:14 -0700 (PDT) Received: by 10.220.118.147 with HTTP; Wed, 18 Apr 2012 14:01:13 -0700 (PDT) In-Reply-To: <4F8EFC17.2060804@gmx.de> References: <002e01cd1d82$297b8fd0$7c72af70$@acm.org> <4F8EFC17.2060804@gmx.de> Date: Wed, 18 Apr 2012 23:01:13 +0200 Message-ID: Subject: Re: Has the AOO 3.4 RC been released? From: Rob Weir To: ooo-dev@incubator.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2012 at 7:38 PM, Christoph Jopp wrote: > > > Am 18.04.2012 19:17, schrieb Kay Schenk: >> On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir wrote: >> >>> On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton >>> wrote: >>>> Michael, I am curious what has you be interested in the availability o= f >>> an AOO 3.4 Release Candidate. >>>> >>>> =C2=A01. What does it say to you when a project build set is designate= d a >>> "Release Candidate"? >>>> >>>> =C2=A02. What use would you make of such a designated build different = from a >>> developer snapshot and an actual release (i.e., AOO 3.4[.0])? >>>> >>> >>> I wonder if there might be some language misunderstanding when we say >>> casually, "We'll soon be voting on a Release Candidate"? >>> >>> To some this could mean we will have a vote to label a particular >>> build as a "Release Candidate". =C2=A0That interpretation would explain >>> some of the post we've been seeing. =C2=A0But that is not how it really >>> works. >>> >>> What actually happens is two things: >>> >>> 1) The Release Manager (Juergen) declares that a particular build is >>> the Release Candidate. >>> >>> 2) The PMC then votes on whether or not to release the Release Candidat= e. >>> >>> >>> When we say "vote on a Release Candidate", some readers might think >>> that we're voting to make the Release Candidate. =C2=A0But we're really >>> voting to release the Release Candidate. =C2=A0Like when I vote for >>> candidate for US President, I'm not voting to make him a candidate. >>> I'm voting to make him President. >>> >> >> A further point of clarification. Does "Release Candidate" in the ASF ha= ve >> the same meaning as the traditional meaning. See, for example: >> >> http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candida= te >> >> Given this definition, a Release Candidate means the "final" test before >> the actual "release". >> >> So, to me, and perhaps others, a "release candidate" is NOT the same as = a >> release. And, to me, a "release candidate" as opposed to a "release" >> implies some predetermined time announced to the public at large, for FI= NAL >> testing -- seems like 2 weeks is typical. >> >> I am not sure at this point if this historical definition applies in the >> ASF. >> >> I think it would be valuable to head up a new thread on this -- "What it >> means to vote on a release candidate at the ASF" -- or something similar= so >> folks have a better understanding of "release candidates"/"release" at t= he >> ASF. > > I might be totally wrong, but I think the main difference is that this > project as long as it is a podling does not release anything. > > The one who releases is the Incubator project and the podling (PPMC) > presents (after voting) the Incubator project a "candidate to be > released". Then the Incubator project votes whether it should be > officially released or not. > The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a "candidate". Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. > So all that can be checked for bugs and regressions are the unofficial > snapshots. > Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this. However, to the extent we want to take an engineering-informed approach to QA, and make optimal use of volunteer time, and use this effort in a way that best improves product quality, then we want to be testing much earlier in the project cycle. That is why Lily sent several notes to the list, months ago, asking for help testing AOO dev snapshots. I don't think anyone offered to help, despite these several requests :-( -Rob > Is this correct? > > Christoph > >> >> >>> >>> -Rob >>> >>>> =C2=A0- Dennis >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Michael Acevedo [mailto:vea1083@gmail.com] >>>> Sent: Tuesday, April 17, 2012 11:36 >>>> To: Apache OpenOffice >>>> Subject: Has the AOO 3.4 RC been released? >>>> >>>> Hi, >>>> >>>> I was wondering if the AOO 3.4 Release Candidate is now available for >>>> download? I see an entry in the Wiki that says so. >>>> >>>> Many Thanks >>>> >>>> -- >>>> Best, >>>> Michael >>>> >>> >> >> >>