incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <orc...@apache.org>
Subject [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Date Sat, 21 Apr 2012 20:01:15 GMT
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:jogischmidt@googlemail.com] 
Sent: Friday, April 20, 2012 17:58
To: ooo-dev@incubator.apache.org; ooo-private@incubator.apache.org
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).

[ ... ]


Mime
View raw message