incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maho NAKATA <m...@apache.org>
Subject Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Date Thu, 26 Apr 2012 09:39:53 GMT
BTW:

FreeBSD ports tree has been updated to 3.4rc1.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice-3-devel/Makefile?rev=1.531;content-type=text%2Fx-cvsweb-markup

and also I'm heading for openoffice-3 port.
http://www.freebsd.org/cgi/query-pr.cgi?pr=167305
thanks
 Nakaa Maho

From: "Dennis E. Hamilton" <orcmid@apache.org>
Subject: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Date: Sat, 21 Apr 2012 13:01:15 -0700

> 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