incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Date Sat, 21 Apr 2012 23:21:55 GMT

On 04/21/2012 01:01 PM, Dennis E. Hamilton wrote:
> What does release-candidate voting at the Apache OpenOffice podling
> mean?
> Is it is just an assessment of support/sentiment, or is there more
> involved?
> The ballot has this phrasing:
> "But we invite all people to vote (non-binding) on this RC. We would
> like to provide a release that is supported by the majority of our
> project members.
> +1 Release this package as Apache OpenOffice 3.4 (incubating) 0 Don't
> care -1 Do not release this package because..."
> I suggest that there are binding PPMC votes on this ballot.  They are
> binding with respect to whether or not the release candidate will be
> submitted to the Incubator PMC for its consideration.
> While non-PPMC/-committer participants can of course vote their
> sentiment, there is something more valuable to be achieved in this
> process.
> Committers and PPMC members are expected to cast informed ballots.
> If any contributor casts a "-1", it should be accompanied by a clear,
> specific explanation and suggestion of actions that would cure the
> situation.
> Here is something that all project contributors can participate in,
> with or without voting:
> It is valuable to download the source code and confirm that binaries
> can be built.

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.

Meanwhile, I will download the source and try my hand...just in case. I 
DO want to vote, and vote correctly.

I have had NO issues with the binary I now have.

> It is valuable to download the binaries and confirm that they install
> properly under a variety of conditions.
> It is especially valuable to verify functions and operations that are
> important to you as an user of who desires to use
> Apache OpenOffice 3.4 as an upgrade.  If this is your first try at
> testing a release in any way, all the better.
> It is also useful to confirm whether the same problem reported by
> someone else is also occurring for others.
> Rather than have many people conduct and confirm the same successes,
> it is useful for contributors to explore areas not previously
> reported on.  It is particularly valuable to examine areas where
> there have been difficulties in the past to see if there is any
> change: improvement or degradation.
> Lily Zhao, Oliver-Rainer Wittman, and others have created wiki pages
> that can be used to help people organize their QA investigations and
> reports.
> There is a general page on the Apache OpenOffice Community Wiki with
> a table for addition of results:
> <>.
> This is for general trials at installation and inspection of
> functions, rather than specific test cases.  To add to this table, a
> Community Wiki registration is required.
> (Note: please use the page above for casual test reports, including
> of installation failures, rather than adding comments to the Release
> Candidate and Developer Snapshot pages.  Help us collect these in a
> small number of places.)
> Test cases are defined on the Wiki at
> <>.  You can
> add or update test cases.  Registration on the Wiki
> (different than the Community Wiki) is required to update these
> pages.
> Test results can be added on the Wiki at
> <>.
> Registration on the Wiki is required.  Editing is the
> same as for any MediaWiki installation, just like Wikipedia.
> There is an overall Release-QA-Plan for background:
> <>.
>  - Dennis
> BACKGROUND CONSIDERATIONS -------------------------
> When a release candidate is voted on by the IPMC, it is *not* a
> statement about the quality of the release with regard to its
> function and reliability.  It is an assessment of specific measures
> releasable code must satisfy, regardless of its function.  There is
> no direct relationship to quality of the release as usable software.
> The IPMC determination is more about the completeness of the source,
> the IP clearance of the source code, and that everything necessary to
> build run-time versions of the code is provided.  The binaries, the
> most important part for users, are assessed mainly for having been
> built from the released source, being certified as such by the
> release manager(s), and satisfaction certain additional requirements
> concerning dependencies, notices, and honoring of licenses.
> It might be that a serious quality issue, a release-blocker, is
> identified by the IPMC or the project itself before release approval
> happens.  In that case, on agreement over the facts and severity, the
> project can withdraw the release candidate and come back another
> day.
> But, in general, the quality of the product as useful software is not
> part of the IPMC determination.  IT IS ASSUMED THAT THE
> regard to the quality of the product itself and what users,
> especially of the binaries, can rely upon.
> First, committers and anyone else can conduct the same level of
> assessment that the IPMC will to verify that release conditions are
> satisfied.
> Even more valuable is to participate in a coherent Quality Assurance
> inspections that provide coverage of features that are important to
> you.  This is particularly important in detecting possible
> regressions with regard to functionality that is currently being
> depended on.  It is also valuable to ensure that a defect that was
> previously a problem has been cured or not.  This is where many
> individuals may contribute.
> QA reports can be affirmative about areas that are working.  "I
> installed it and it didn't crash" is useful confirmation, but going
> beyond that is even more valuable.  Anything of concern can be
> reported and bugs should be reported where there is some very
> specific detail that is an issue.
> Defects that you report are not necessarily release blockers.  But if
> something that appears to be a show-stopper arises, the sooner that
> can be reported, reproduced, and assessed the better.
> -----Original Message----- From: J├╝rgen Schmidt
> [] Sent: Friday, April 20, 2012
> 17:58 To:;
> Subject: [VOTE] Release Apache
> OpenOffice 3.4 (incubating) RC1
> Hi all,
> this is a call for vote on releasing the following candidate as
> Apache OpenOffice 3.4 (incubating). This will be the first incubator
> release for Apache OpenOffice and a key milestone to continue the
> success of
> [ ... ]
> For a detailed feature overview please see the release notes under
> The release candidate artifacts (source release, as well as binary
> releases for 16 languages) and further information how to verify and
> review Apache OpenOffice 3.4 (incubating) can be found on the
> following wiki page:
> Please vote on releasing this package as Apache OpenOffice 3.4
> (incubating).
> [ ... ]


"Women and cats will do as they please,
  and men and dogs should relax and get used to the idea."
                                     -- Robert Heinlein

View raw message