On Apr 22, 2012, at 7:51 AM, Rob Weir wrote: > On Sat, Apr 21, 2012 at 7:21 PM, Kay Schenk <kay.sch...@gmail.com> wrote: >> >> > > <snip> > >> OK, I have a question on this one. MUST we download and build or can we vote >> on an already built (binary) version? There was some discussion about this, >> and, yes, there are notes about this on general information for Apache >> releases, but...I jsut noticed the vote from Hagar Delest which implies he >> used a binary so this is why I ask. >> > > You are not required to build the AOO RC in order to vote. Remember, > participating in the review and approval of releases is one of the > most basic responsibilities of *all* PMC members. We have selected > PMC members with a wide range of relevant skills, not all of them are > coders. So not everyone is expected to build. But I would expect > that everyone who votes will find something that they can do to help > verify the RC. For example, installing, verifying a translation, > reviewing the LICENSE and NOTICE file, reviewing the RAT scan output, > etc. > > Remember, unlike a much smaller project at Apache, we cannot assume > that there is even a single person who understands all aspects of the > product. Not even one. Those who can build on Windows might not be > the same ones who can verify the Gallacian translation, and those who > understand the details of the LICENSE requirements might not have > access to a 64-bit Linux machine to test that install. So we need to > rely on others. > > So, a +1 to me means three things: > > 1) I have verified what I can verify and it looks acceptable for a release. > > 2) No one else has reported a credible, substantial issue with the RC. > > 3) I believe that there has been sufficient overall review of the RC. > > So obviously my vote can change based on what others find and report > about the RC. In particular I plan to test a few install scenarios > and if they work out, I'll vote +1 later today. But if someone later > finds a serious issue, then I could change my vote.
There are two types of artifacts in the release candidate. (A) The source release. This is the official package and what the VOTE is ultimately about. (B) Built installation binaries. These are for user's convenience and are not "official". This includes the SDK. The SDK and Binaries are missing the DISCLAIMER file. Is a missing Incubation DISCLAIMER in a binary package enough to prevent release? I think probably not, but this may be an edge case. The application pop-ups do mention "Incubation" and every page linked back to the www.openoffice.org shows the Disclaimer... One approach would be to move forward with AOO 3.4 and plan a AOO 3.4.1 (3.5) in a couple months to clean up all these technical loose ends in advance of Graduation? My next steps for my VOTE will be to review the Source Release, Build, and RAT scans with spot testing the excludes. Regards, Dave
