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" <orc...@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:jogischm...@googlemail.com] > Sent: Friday, April 20, 2012 17:58 > To: ooo-dev@incubator.apache.org; ooo-priv...@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). > > [ ... ] >
