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:
PARTICIPATE IN QUALITY-ASSURANCE COVERAGE OF THE CANDIDATE
It is valuable to download the source code and confirm that binaries can be
built.
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 OpenOffice.org 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:
<https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+RC+Build+Test+Report>.
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 OpenOffice.org Wiki at
<http://wiki.services.openoffice.org/wiki/QA/TestCases/>. You can add or
update test cases. Registration on the OpenOffice.org Wiki (different than the
Community Wiki) is required to update these pages.
Test results can be added on the OpenOffice.org Wiki at
<http://wiki.services.openoffice.org/wiki/QA/TestResults>. Registration on the
OpenOffice.org Wiki is required. Editing is the same as for any MediaWiki
installation, just like Wikipedia.
There is an overall Release-QA-Plan for background:
<https://cwiki.apache.org/confluence/display/OOOUSERS/Release-QA-Plan>.
- Dennis
BACKGROUND CONSIDERATIONS
-------------------------
WHAT MAKES A RELEASE CANDIDATE ELIGIBLE TO BE A RELEASE?
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 PROJECT/PODLING HAS DONE
WHATEVER IS NECESSARY to be satisfied with regard to the quality of the product
itself and what users, especially of the binaries, can rely upon.
WHAT CAN SUPPORTERS AND COMMITTERS TO DO TO MAKE A GOOD RELEASE?
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 [mailto:[email protected]]
Sent: Friday, April 20, 2012 17:58
To: [email protected]; [email protected]
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
OpenOffice.org.
[ ... ]
For a detailed feature overview please see the release notes under
https://cwiki.apache.org/OOOUSERS/aoo-34-release-notes.html.
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:
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+%28incubating%29+Release+Candidate
Please vote on releasing this package as Apache OpenOffice 3.4 (incubating).
[ ... ]
