You are viewing a plain text version of this content. The canonical link for it is here.
Posted to qa@openoffice.apache.org by "Dennis E. Hamilton" <or...@apache.org> on 2012/04/21 22:01:15 UTC
[DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
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).
[ ... ]
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Maho NAKATA <ma...@apache.org>.
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" <or...@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).
>
> [ ... ]
>
RE: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by "Dennis E. Hamilton" <or...@apache.org>.
My oversight:
There is a consolidated link to all of the QA locations for the Release Candidate at
<http://wiki.services.openoffice.org/wiki/Quality_Assurance#Apache_OpenOffice_3.4>.
-----Original Message-----
From: Dennis E. Hamilton [mailto:orcmid@apache.org]
Sent: Saturday, April 21, 2012 13:01
To: ooo-dev@incubator.apache.org
Cc: 'xia zhao'; ooo-qa@incubator.apache.org
Subject: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
[ ... ]
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
[ ... ]
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Maho NAKATA <ma...@apache.org>.
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" <or...@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).
>
> [ ... ]
>
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Kay Schenk <ka...@gmail.com>.
On 04/22/2012 08:05 AM, RGB ES wrote:
> El d�a 22 de abril de 2012 16:51, Rob Weir<ro...@apache.org> escribi�:
>> On Sat, Apr 21, 2012 at 7:21 PM, Kay Schenk<ka...@gmail.com> wrote:
>>>
>>>
>>
>> <snip>
>>
>>> 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.
>>>
>>
>> You are not required to build the AOO RC in order to vote. � Remember,
>> participating in the review and approval of releases is one of the
>> most basic responsibilities of *all* PMC members. � We have selected
>> PMC members with a wide range of relevant skills, not all of them are
>> coders. �So not everyone is expected to build. �But I would expect
>> that everyone who votes will find something that they can do to help
>> verify the RC. � For example, installing, verifying a translation,
>> reviewing the LICENSE and NOTICE file, reviewing the RAT scan output,
>> etc.
>>
>> Remember, unlike a much smaller project at Apache, we cannot assume
>> that there is even a single person who understands all aspects of the
>> product. �Not even one. �Those who can build on Windows might not be
>> the same ones who can verify the Gallacian translation, and those who
>> understand the details of the LICENSE requirements might not have
>> access to a 64-bit Linux machine to test that install. �So we need to
>> rely on others.
>>
>> So, a +1 to me means three things:
>>
>> 1) I have verified what I can verify and it looks acceptable for a release.
>>
>> 2) No one else has reported a credible, substantial issue with the RC.
>>
>> 3) I believe that there has been sufficient overall review of the RC.
>>
>> So obviously my vote can change based on what others find and report
>> about the RC. �In particular I plan to test a few install scenarios
>> and if they work out, I'll vote +1 later today. �But if someone later
>> finds a serious issue, then I could change my vote.
>>
>> -Rob
>
> Thanks Rob for the clarification (I had the same doubt expressed by
> Kay Schenk). I installed and used the build on my openSUSE 11.4, 64
> bits box without problems so this is a huge
>
> +1
>
> from me (PPMC member: rgb-es @ apache)
>
> Regards
> Ricardo
Yes, Rob, thanks for this clarification. I am relatively confident I
could, in fact, build AOO 3.4 having done such things many times in the
past, but it would definitely take time away from other things I need to
be doing to get ready for our release.
--
------------------------------------------------------------------------
MzK
"Women and cats will do as they please,
and men and dogs should relax and get used to the idea."
-- Robert Heinlein
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by RGB ES <rg...@gmail.com>.
El día 22 de abril de 2012 16:51, Rob Weir <ro...@apache.org> escribió:
> On Sat, Apr 21, 2012 at 7:21 PM, Kay Schenk <ka...@gmail.com> wrote:
>>
>>
>
> <snip>
>
>> 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.
>>
>
> You are not required to build the AOO RC in order to vote. Remember,
> participating in the review and approval of releases is one of the
> most basic responsibilities of *all* PMC members. We have selected
> PMC members with a wide range of relevant skills, not all of them are
> coders. So not everyone is expected to build. But I would expect
> that everyone who votes will find something that they can do to help
> verify the RC. For example, installing, verifying a translation,
> reviewing the LICENSE and NOTICE file, reviewing the RAT scan output,
> etc.
>
> Remember, unlike a much smaller project at Apache, we cannot assume
> that there is even a single person who understands all aspects of the
> product. Not even one. Those who can build on Windows might not be
> the same ones who can verify the Gallacian translation, and those who
> understand the details of the LICENSE requirements might not have
> access to a 64-bit Linux machine to test that install. So we need to
> rely on others.
>
> So, a +1 to me means three things:
>
> 1) I have verified what I can verify and it looks acceptable for a release.
>
> 2) No one else has reported a credible, substantial issue with the RC.
>
> 3) I believe that there has been sufficient overall review of the RC.
>
> So obviously my vote can change based on what others find and report
> about the RC. In particular I plan to test a few install scenarios
> and if they work out, I'll vote +1 later today. But if someone later
> finds a serious issue, then I could change my vote.
>
> -Rob
Thanks Rob for the clarification (I had the same doubt expressed by
Kay Schenk). I installed and used the build on my openSUSE 11.4, 64
bits box without problems so this is a huge
+1
from me (PPMC member: rgb-es @ apache)
Regards
Ricardo
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Andre Fischer <af...@a-w-f.de>.
On 25.04.2012 04:18, Dave Fisher wrote:
>
> On Apr 24, 2012, at 12:18 PM, Rob Weir wrote:
>
>> On Tue, Apr 24, 2012 at 2:39 PM, Dave Fisher<da...@comcast.net> wrote:
>>>
>>> On Apr 22, 2012, at 1:21 PM, Dave Fisher wrote:
>>>
[...]
>>> (3) When building from source there was no warning about the inclusion of Category B? I think that the Building Guide should be edited to more clearly explain the ext_sources and ext_libraries. I know we have the information. It is more making this clear. Again, I'm not sure if it a SHOULD or a MUST for a build to pause and get explicit permission to download category B.
>>>
>>
>> If you build with the default build flags, then you get no category B
>> code. If you want category B code then you need to explicitly add
>> those command-line build flags. Maybe the impact of these flags needs
>> to be clearer in the Building Guide?
>
> Yes, that would be great.
I tried to do that (see [1]). Please check if I succeeded.
Andre
[1]
http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide_AOO#Configuration_and_bootstrapping
[...]
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Dave Fisher <da...@comcast.net>.
On Apr 24, 2012, at 12:18 PM, Rob Weir wrote:
> On Tue, Apr 24, 2012 at 2:39 PM, Dave Fisher <da...@comcast.net> wrote:
>>
>> On Apr 22, 2012, at 1:21 PM, Dave Fisher wrote:
>>
>>>
>>> On Apr 22, 2012, at 1:02 PM, Rob Weir wrote:
>>>
>>>> On Sun, Apr 22, 2012 at 3:57 PM, Dave Fisher <da...@comcast.net> wrote:
>>>>>
>>>>> On Apr 22, 2012, at 12:47 PM, Rob Weir wrote:
>>>>>
>>>>>> <snip>
>>>>>
>>>>>
>>>>> You snipped out the important part:
>>>>>
>>>>
>>>> Sorry, thought you answered your own question there. But since you
>>>> bring it up, there is no requirement for a DISCLAIMER file. There is
>>>> however a requirement for making the user aware of the incubation
>>>> disclaimer. See this page, where several options are listed:
>>>>
>>>> http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer
>>>
>>> Keep in mind that page is clearly labeled as a "DRAFT".
>>>
>>> http://incubator.apache.org/guides/releasemanagement.html#status
>>>
>>> The DISCLAIMER file is certainly in the correct place in the Source distribution.
>>
>> Well, I was not correct here. It is in the SVN, but fails to make it into any of the distributions.
>>
>> I did a MacOSX build, reviewed the NOTICE, LICENSE, rat-exclude and rat output from a nightly build.
>>
>> An amazing job was done with the Headers and the RAT report!
>>
>> Here are my concerns:
>>
>> (1) DISCLAIMER ought to be included in all packages. We'll have to see if this is a SHOULD or a MUST.
>>
>
> I think we need to make it clear to the user that this is a project
> under incubation. There are several ways of doing this. Standalone
> DISCLAIMER is one way. Adding to README file is another explicitly
> called out in the podling release guide.
>
>> (2) LICENSE contains copyright statements which ought to be part of the NOTICE file. Again we'll see if this is a SHOULD or a MUST.
>>
>
> Do you have some examples?
From the LICENSE:
For main/i18npool/source/breakiterator/data/*.txt and
International Components for Unicode - built in main/icu/
- ICU license
This is derived work based on:
ftp://ftp.software.ibm.com/software/globalization/icu/3.2/
License of the origin and the derived work:
ICU License - ICU 1.8.1 and later
COPYRIGHT AND PERMISSION NOTICE
Copyright (c) 1995-2003 International Business Machines Corporation and others
All rights reserved.
> As I understand it, unless it is a required notice per the license,
> the only copyrights that go into NOTICE are the ASF copyright and the
> Oracle one which was relocated from the source files when the ALv2
> headers were added. We're not required to put every copyright
> statement in NOTICE.
Actually I think this is where these copyright notices need to be. There has been discussion on general@i.a.o and the issue is not clear.
I think we are fine, but I also think that there will be discussion about it on the IPMC portion of the VOTE.
>
>
>> (3) When building from source there was no warning about the inclusion of Category B? I think that the Building Guide should be edited to more clearly explain the ext_sources and ext_libraries. I know we have the information. It is more making this clear. Again, I'm not sure if it a SHOULD or a MUST for a build to pause and get explicit permission to download category B.
>>
>
> If you build with the default build flags, then you get no category B
> code. If you want category B code then you need to explicitly add
> those command-line build flags. Maybe the impact of these flags needs
> to be clearer in the Building Guide?
Yes, that would be great.
>
> I don't think you really want the build system to actually pause and
> wait for human input. That might complicated the Buildbot....
Somehow it has to be clear to the user when category B is consumed.
Regards,
Dave
>
>> Regards,
>> Dave
>>
>>
>>>
>>> I think that I answered the question, but I would like to ask our project Mentors if this will be an issue in IPMC voting. I've seen enough on general@i.a.o to know that it may be for some and not others.
>>>
>>> So, while this is not a problem for me, if it is likely IPMC will request an RC2 over this we should know now.
>>>
>>> Regards,
>>> Dave
>>>
>>>>
>>>> -Rob
>>>>
>>>>> The SDK and Binaries are missing the DISCLAIMER file. Is a missing Incubation DISCLAIMER in a binary package enough to prevent release? I think probably not, but this may be an edge case. The application pop-ups do mention "Incubation" and every page linked back to thewww.openoffice.org shows the Disclaimer...
>>>>>
>>>>> Regards,
>>>>> Dave
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> -Rob
>>>>>
>>>
>>
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Rob Weir <ro...@apache.org>.
On Tue, Apr 24, 2012 at 2:39 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Apr 22, 2012, at 1:21 PM, Dave Fisher wrote:
>
>>
>> On Apr 22, 2012, at 1:02 PM, Rob Weir wrote:
>>
>>> On Sun, Apr 22, 2012 at 3:57 PM, Dave Fisher <da...@comcast.net> wrote:
>>>>
>>>> On Apr 22, 2012, at 12:47 PM, Rob Weir wrote:
>>>>
>>>>> <snip>
>>>>
>>>>
>>>> You snipped out the important part:
>>>>
>>>
>>> Sorry, thought you answered your own question there. But since you
>>> bring it up, there is no requirement for a DISCLAIMER file. There is
>>> however a requirement for making the user aware of the incubation
>>> disclaimer. See this page, where several options are listed:
>>>
>>> http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer
>>
>> Keep in mind that page is clearly labeled as a "DRAFT".
>>
>> http://incubator.apache.org/guides/releasemanagement.html#status
>>
>> The DISCLAIMER file is certainly in the correct place in the Source distribution.
>
> Well, I was not correct here. It is in the SVN, but fails to make it into any of the distributions.
>
> I did a MacOSX build, reviewed the NOTICE, LICENSE, rat-exclude and rat output from a nightly build.
>
> An amazing job was done with the Headers and the RAT report!
>
> Here are my concerns:
>
> (1) DISCLAIMER ought to be included in all packages. We'll have to see if this is a SHOULD or a MUST.
>
I think we need to make it clear to the user that this is a project
under incubation. There are several ways of doing this. Standalone
DISCLAIMER is one way. Adding to README file is another explicitly
called out in the podling release guide.
> (2) LICENSE contains copyright statements which ought to be part of the NOTICE file. Again we'll see if this is a SHOULD or a MUST.
>
Do you have some examples?
As I understand it, unless it is a required notice per the license,
the only copyrights that go into NOTICE are the ASF copyright and the
Oracle one which was relocated from the source files when the ALv2
headers were added. We're not required to put every copyright
statement in NOTICE.
> (3) When building from source there was no warning about the inclusion of Category B? I think that the Building Guide should be edited to more clearly explain the ext_sources and ext_libraries. I know we have the information. It is more making this clear. Again, I'm not sure if it a SHOULD or a MUST for a build to pause and get explicit permission to download category B.
>
If you build with the default build flags, then you get no category B
code. If you want category B code then you need to explicitly add
those command-line build flags. Maybe the impact of these flags needs
to be clearer in the Building Guide?
I don't think you really want the build system to actually pause and
wait for human input. That might complicated the Buildbot....
> Regards,
> Dave
>
>
>>
>> I think that I answered the question, but I would like to ask our project Mentors if this will be an issue in IPMC voting. I've seen enough on general@i.a.o to know that it may be for some and not others.
>>
>> So, while this is not a problem for me, if it is likely IPMC will request an RC2 over this we should know now.
>>
>> Regards,
>> Dave
>>
>>>
>>> -Rob
>>>
>>>> The SDK and Binaries are missing the DISCLAIMER file. Is a missing Incubation DISCLAIMER in a binary package enough to prevent release? I think probably not, but this may be an edge case. The application pop-ups do mention "Incubation" and every page linked back to thewww.openoffice.org shows the Disclaimer...
>>>>
>>>> Regards,
>>>> Dave
>>>>
>>>>
>>>>
>>>>>
>>>>> -Rob
>>>>
>>
>
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Dave Fisher <da...@comcast.net>.
On Apr 22, 2012, at 1:21 PM, Dave Fisher wrote:
>
> On Apr 22, 2012, at 1:02 PM, Rob Weir wrote:
>
>> On Sun, Apr 22, 2012 at 3:57 PM, Dave Fisher <da...@comcast.net> wrote:
>>>
>>> On Apr 22, 2012, at 12:47 PM, Rob Weir wrote:
>>>
>>>> <snip>
>>>
>>>
>>> You snipped out the important part:
>>>
>>
>> Sorry, thought you answered your own question there. But since you
>> bring it up, there is no requirement for a DISCLAIMER file. There is
>> however a requirement for making the user aware of the incubation
>> disclaimer. See this page, where several options are listed:
>>
>> http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer
>
> Keep in mind that page is clearly labeled as a "DRAFT".
>
> http://incubator.apache.org/guides/releasemanagement.html#status
>
> The DISCLAIMER file is certainly in the correct place in the Source distribution.
Well, I was not correct here. It is in the SVN, but fails to make it into any of the distributions.
I did a MacOSX build, reviewed the NOTICE, LICENSE, rat-exclude and rat output from a nightly build.
An amazing job was done with the Headers and the RAT report!
Here are my concerns:
(1) DISCLAIMER ought to be included in all packages. We'll have to see if this is a SHOULD or a MUST.
(2) LICENSE contains copyright statements which ought to be part of the NOTICE file. Again we'll see if this is a SHOULD or a MUST.
(3) When building from source there was no warning about the inclusion of Category B? I think that the Building Guide should be edited to more clearly explain the ext_sources and ext_libraries. I know we have the information. It is more making this clear. Again, I'm not sure if it a SHOULD or a MUST for a build to pause and get explicit permission to download category B.
Regards,
Dave
>
> I think that I answered the question, but I would like to ask our project Mentors if this will be an issue in IPMC voting. I've seen enough on general@i.a.o to know that it may be for some and not others.
>
> So, while this is not a problem for me, if it is likely IPMC will request an RC2 over this we should know now.
>
> Regards,
> Dave
>
>>
>> -Rob
>>
>>> The SDK and Binaries are missing the DISCLAIMER file. Is a missing Incubation DISCLAIMER in a binary package enough to prevent release? I think probably not, but this may be an edge case. The application pop-ups do mention "Incubation" and every page linked back to thewww.openoffice.org shows the Disclaimer...
>>>
>>> Regards,
>>> Dave
>>>
>>>
>>>
>>>>
>>>> -Rob
>>>
>
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Albino Biasutti Neto <bi...@gmail.com>.
Hi.
2012/4/22 Claudio Filho <fi...@gmail.com>
> Hi
>
> 2012/4/22 Rob Weir <ro...@apache.org>:
> > Blog post:
> >
> http://www.escritoriolivre.org/artigo/extens%C3%B5es-no-apache-openoffice
>
> This is Luiz, our old OOo/BrOo user group leader in Brazil.
<snip>
> And how
> we haven't a brazilian portuguese list here, i started the work
> (localization and some tests) in this site, our brazilian comunity
> seed.
>
</snip>
Yes! The Claudio started the work (localization and some tests), our
brazilian comunity. :)
I was inspired by him.
>
> Best,
> Claudio
>
The tests is successfully. :)
Best,
Albino @bino28
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Claudio Filho <fi...@gmail.com>.
Hi
2012/4/22 Rob Weir <ro...@apache.org>:
> Blog post:
> http://www.escritoriolivre.org/artigo/extens%C3%B5es-no-apache-openoffice
This is Luiz, our old OOo/BrOo user group leader in Brazil. And how
we haven't a brazilian portuguese list here, i started the work
(localization and some tests) in this site, our brazilian comunity
seed.
Best,
Claudio
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Rob Weir <ro...@apache.org>.
Some feedback (via our new identi.ca account) from a user installing
the RC on 64-bit Linux Mint. It worked well, including the extensions
he used.
Original dent: http://identi.ca/notice/92977977
Blog post:
http://www.escritoriolivre.org/artigo/extens%C3%B5es-no-apache-openoffice
Translation of the blog post:
http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.escritoriolivre.org%2Fartigo%2Fextens%25C3%25B5es-no-apache-openoffice&act=url
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Albino Biasutti Neto <bi...@gmail.com>.
Hi.
2012/4/22 Rob Weir <ro...@apache.org>
> On Sun, Apr 22, 2012 at 4:21 PM, Dave Fisher <da...@comcast.net>
> wrote:
> >
> > On Apr 22, 2012, at 1:02 PM, Rob Weir wrote:
> >
> >> On Sun, Apr 22, 2012 at 3:57 PM, Dave Fisher <da...@comcast.net>
> wrote:
> >>>
> >>> On Apr 22, 2012, at 12:47 PM, Rob Weir wrote:
> >>>
> >>>> <snip>
> >>>
> >>>
> >>> You snipped out the important part:
> >>>
> >>
> >> Sorry, thought you answered your own question there. But since you
> >> bring it up, there is no requirement for a DISCLAIMER file. There is
> >> however a requirement for making the user aware of the incubation
> >> disclaimer. See this page, where several options are listed:
> >>
> >>
> http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer
> >
> > Keep in mind that page is clearly labeled as a "DRAFT".
> >
> > http://incubator.apache.org/guides/releasemanagement.html#status
> >
> > The DISCLAIMER file is certainly in the correct place in the Source
> distribution.
> >
> > I think that I answered the question, but I would like to ask our
> project Mentors if this will be an issue in IPMC voting. I've seen enough
> on general@i.a.o to know that it may be for some and not others.
> >
>
> Not an issue for me either. That fact that OpenOffice is under
> incubation at Apache has been leading tech news for nearly a year now.
> People who know nothing else about Apache know this fact.
>
> > So, while this is not a problem for me, if it is likely IPMC will
> request an RC2 over this we should know now.
> >
>
> But worth taking it through the voting process, IMHO, to see if there
> are any other issues. One big issue or several smaller ones could be
> enough for us to kill the vote prematurely. But it would be extremely
> inefficient to waste 48-hours preparing another RC every time someone
> finds a single thing that is not consistent with the
> self-contradictory draft incubation guidelines. There is no better
> time than the present to do a complete review.
>
> -Rob
>
> > Regards,
> > Dave
> >
> >>
> >> -Rob
> >>
> >>> The SDK and Binaries are missing the DISCLAIMER file. Is a missing
> Incubation DISCLAIMER in a binary package enough to prevent release? I
> think probably not, but this may be an edge case. The application pop-ups
> do mention "Incubation" and every page linked back to
> thewww.openoffice.org shows the Disclaimer...
> >>>
> >>> Regards,
> >>> Dave
> >>>
> >>>
> >>>
> >>>>
> >>>> -Rob
> >>>
> >
>
I installed some extensions in aoo: cogroo, vero and smart, congratulation!
:)
More tests... ;)
Best,
Albino @bino28
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating)
RC1
Posted by Juergen Schmidt <jo...@googlemail.com>.
On Monday, 23. April 2012 at 04:29, Rob Weir wrote:
> On Sun, Apr 22, 2012 at 4:21 PM, Dave Fisher <da...@comcast.net> wrote:
> >
> > On Apr 22, 2012, at 1:02 PM, Rob Weir wrote:
> >
> > > On Sun, Apr 22, 2012 at 3:57 PM, Dave Fisher <da...@comcast.net> wrote:
> > > >
> > > > On Apr 22, 2012, at 12:47 PM, Rob Weir wrote:
> > > >
> > > > > <snip>
> > > >
> > > >
> > > > You snipped out the important part:
> > >
> > > Sorry, thought you answered your own question there. But since you
> > > bring it up, there is no requirement for a DISCLAIMER file. There is
> > > however a requirement for making the user aware of the incubation
> > > disclaimer. See this page, where several options are listed:
> > >
> > > http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer
> >
> > Keep in mind that page is clearly labeled as a "DRAFT".
> >
> > http://incubator.apache.org/guides/releasemanagement.html#status
> >
> > The DISCLAIMER file is certainly in the correct place in the Source distribution.
> >
> > I think that I answered the question, but I would like to ask our project Mentors if this will be an issue in IPMC voting. I've seen enough on general@i.a.o to know that it may be for some and not others.
>
> Not an issue for me either. That fact that OpenOffice is under
> incubation at Apache has been leading tech news for nearly a year now.
> People who know nothing else about Apache know this fact.
>
> > So, while this is not a problem for me, if it is likely IPMC will request an RC2 over this we should know now.
>
> But worth taking it through the voting process, IMHO, to see if there
> are any other issues. One big issue or several smaller ones could be
> enough for us to kill the vote prematurely. But it would be extremely
> inefficient to waste 48-hours preparing another RC every time someone
> finds a single thing that is not consistent with the
> self-contradictory draft incubation guidelines. There is no better
> time than the present to do a complete review.
>
>
Exactly, because many people prefer to give feedback on RC's only. So let us continue to collect all the feedback and ideally people create issues for all found problems and request the show stopper flag. That makes it easier for others who intend to fix these problems to get an overview.
Thanks
Juergen
>
> -Rob
>
> > Regards,
> > Dave
> >
> > >
> > > -Rob
> > >
> > > > The SDK and Binaries are missing the DISCLAIMER file. Is a missing Incubation DISCLAIMER in a binary package enough to prevent release? I think probably not, but this may be an edge case. The application pop-ups do mention "Incubation" and every page linked back to thewww.openoffice.org shows the Disclaimer...
> > > >
> > > > Regards,
> > > > Dave
> > > >
> > > >
> > > >
> > > > >
> > > > > -Rob
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Rob Weir <ro...@apache.org>.
On Sun, Apr 22, 2012 at 4:21 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Apr 22, 2012, at 1:02 PM, Rob Weir wrote:
>
>> On Sun, Apr 22, 2012 at 3:57 PM, Dave Fisher <da...@comcast.net> wrote:
>>>
>>> On Apr 22, 2012, at 12:47 PM, Rob Weir wrote:
>>>
>>>> <snip>
>>>
>>>
>>> You snipped out the important part:
>>>
>>
>> Sorry, thought you answered your own question there. But since you
>> bring it up, there is no requirement for a DISCLAIMER file. There is
>> however a requirement for making the user aware of the incubation
>> disclaimer. See this page, where several options are listed:
>>
>> http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer
>
> Keep in mind that page is clearly labeled as a "DRAFT".
>
> http://incubator.apache.org/guides/releasemanagement.html#status
>
> The DISCLAIMER file is certainly in the correct place in the Source distribution.
>
> I think that I answered the question, but I would like to ask our project Mentors if this will be an issue in IPMC voting. I've seen enough on general@i.a.o to know that it may be for some and not others.
>
Not an issue for me either. That fact that OpenOffice is under
incubation at Apache has been leading tech news for nearly a year now.
People who know nothing else about Apache know this fact.
> So, while this is not a problem for me, if it is likely IPMC will request an RC2 over this we should know now.
>
But worth taking it through the voting process, IMHO, to see if there
are any other issues. One big issue or several smaller ones could be
enough for us to kill the vote prematurely. But it would be extremely
inefficient to waste 48-hours preparing another RC every time someone
finds a single thing that is not consistent with the
self-contradictory draft incubation guidelines. There is no better
time than the present to do a complete review.
-Rob
> Regards,
> Dave
>
>>
>> -Rob
>>
>>> The SDK and Binaries are missing the DISCLAIMER file. Is a missing Incubation DISCLAIMER in a binary package enough to prevent release? I think probably not, but this may be an edge case. The application pop-ups do mention "Incubation" and every page linked back to thewww.openoffice.org shows the Disclaimer...
>>>
>>> Regards,
>>> Dave
>>>
>>>
>>>
>>>>
>>>> -Rob
>>>
>
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Dave Fisher <da...@comcast.net>.
On Apr 22, 2012, at 1:02 PM, Rob Weir wrote:
> On Sun, Apr 22, 2012 at 3:57 PM, Dave Fisher <da...@comcast.net> wrote:
>>
>> On Apr 22, 2012, at 12:47 PM, Rob Weir wrote:
>>
>>> <snip>
>>
>>
>> You snipped out the important part:
>>
>
> Sorry, thought you answered your own question there. But since you
> bring it up, there is no requirement for a DISCLAIMER file. There is
> however a requirement for making the user aware of the incubation
> disclaimer. See this page, where several options are listed:
>
> http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer
Keep in mind that page is clearly labeled as a "DRAFT".
http://incubator.apache.org/guides/releasemanagement.html#status
The DISCLAIMER file is certainly in the correct place in the Source distribution.
I think that I answered the question, but I would like to ask our project Mentors if this will be an issue in IPMC voting. I've seen enough on general@i.a.o to know that it may be for some and not others.
So, while this is not a problem for me, if it is likely IPMC will request an RC2 over this we should know now.
Regards,
Dave
>
> -Rob
>
>> The SDK and Binaries are missing the DISCLAIMER file. Is a missing Incubation DISCLAIMER in a binary package enough to prevent release? I think probably not, but this may be an edge case. The application pop-ups do mention "Incubation" and every page linked back to thewww.openoffice.org shows the Disclaimer...
>>
>> Regards,
>> Dave
>>
>>
>>
>>>
>>> -Rob
>>
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Rob Weir <ro...@apache.org>.
On Sun, Apr 22, 2012 at 3:57 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Apr 22, 2012, at 12:47 PM, Rob Weir wrote:
>
>> <snip>
>
>
> You snipped out the important part:
>
Sorry, thought you answered your own question there. But since you
bring it up, there is no requirement for a DISCLAIMER file. There is
however a requirement for making the user aware of the incubation
disclaimer. See this page, where several options are listed:
http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer
-Rob
> The SDK and Binaries are missing the DISCLAIMER file. Is a missing Incubation DISCLAIMER in a binary package enough to prevent release? I think probably not, but this may be an edge case. The application pop-ups do mention "Incubation" and every page linked back to thewww.openoffice.org shows the Disclaimer...
>
> Regards,
> Dave
>
>
>
>>
>> -Rob
>
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Dave Fisher <da...@comcast.net>.
On Apr 22, 2012, at 12:47 PM, Rob Weir wrote:
> <snip>
You snipped out the important part:
The SDK and Binaries are missing the DISCLAIMER file. Is a missing Incubation DISCLAIMER in a binary package enough to prevent release? I think probably not, but this may be an edge case. The application pop-ups do mention "Incubation" and every page linked back to thewww.openoffice.org shows the Disclaimer...
Regards,
Dave
>
> -Rob
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Rob Weir <ro...@apache.org>.
On Sun, Apr 22, 2012 at 3:23 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Apr 22, 2012, at 7:51 AM, Rob Weir wrote:
>
>> On Sat, Apr 21, 2012 at 7:21 PM, Kay Schenk <ka...@gmail.com> wrote:
>>>
>>>
>>
>> <snip>
>>
>>> 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.
>>>
>>
>> You are not required to build the AOO RC in order to vote. Remember,
>> participating in the review and approval of releases is one of the
>> most basic responsibilities of *all* PMC members. We have selected
>> PMC members with a wide range of relevant skills, not all of them are
>> coders. So not everyone is expected to build. But I would expect
>> that everyone who votes will find something that they can do to help
>> verify the RC. For example, installing, verifying a translation,
>> reviewing the LICENSE and NOTICE file, reviewing the RAT scan output,
>> etc.
>>
>> Remember, unlike a much smaller project at Apache, we cannot assume
>> that there is even a single person who understands all aspects of the
>> product. Not even one. Those who can build on Windows might not be
>> the same ones who can verify the Gallacian translation, and those who
>> understand the details of the LICENSE requirements might not have
>> access to a 64-bit Linux machine to test that install. So we need to
>> rely on others.
>>
>> So, a +1 to me means three things:
>>
>> 1) I have verified what I can verify and it looks acceptable for a release.
>>
>> 2) No one else has reported a credible, substantial issue with the RC.
>>
>> 3) I believe that there has been sufficient overall review of the RC.
>>
>> So obviously my vote can change based on what others find and report
>> about the RC. In particular I plan to test a few install scenarios
>> and if they work out, I'll vote +1 later today. But if someone later
>> finds a serious issue, then I could change my vote.
>
> There are two types of artifacts in the release candidate.
>
I disagree with your interpretation.
> (A) The source release. This is the official package and what the VOTE is ultimately about.
>
Every release must include a source distribution, but that does not
mean that the vote is not also about the binary packages. Remember,
all of the other requirements of Apache releases also pertain to the
binary distributions, including NOTICE, LICENSE, detached signature,
hashes, etc. These are all factors in the vote, therefor the vote
does concern the binary packages as well.
As you know there is no other mechanism for a project to release a
binary except through a vote.
It should be obvious that the source code is not intended to be read
as a literary work. Its primary value is its ability to be compiled
into a binary and used as-is, or modified and and compiled into
derived product. So the functionality and quality of our binary
distribution is of great importance to this project.
> (B) Built installation binaries. These are for user's convenience and are not "official". This includes the SDK.
>
The binaries are official. They are part of the release. They are
voted on. They are signed. They will be uploaded and served up by
Apache-endorsed mirrors. The use the Apache-owned trademarks. I don't
see how you can say they are anything other than official.
Each Apache project must produce a source distribution in its release.
Some will have binary packages as well. Some will not. The
relative priority to give to the binary packages is something each PMC
will decide for itself. This is fine, so long as the source packages
are provided as well. In an end-user facing project it is natural for
the project put some emphasis on the binary packages.
I think we're all aware of the importance of the source releases.
Please don't lecture us on that. After all we have spent months
working on getting the source into good shape for Apache. We get
that. But also please don't insult us, and all the volunteer effort
spent on this project, by saying the binary portions of the release
are not official or are not important.
-Rob
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Dave Fisher <da...@comcast.net>.
On Apr 22, 2012, at 7:51 AM, Rob Weir wrote:
> On Sat, Apr 21, 2012 at 7:21 PM, Kay Schenk <ka...@gmail.com> wrote:
>>
>>
>
> <snip>
>
>> 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.
>>
>
> You are not required to build the AOO RC in order to vote. Remember,
> participating in the review and approval of releases is one of the
> most basic responsibilities of *all* PMC members. We have selected
> PMC members with a wide range of relevant skills, not all of them are
> coders. So not everyone is expected to build. But I would expect
> that everyone who votes will find something that they can do to help
> verify the RC. For example, installing, verifying a translation,
> reviewing the LICENSE and NOTICE file, reviewing the RAT scan output,
> etc.
>
> Remember, unlike a much smaller project at Apache, we cannot assume
> that there is even a single person who understands all aspects of the
> product. Not even one. Those who can build on Windows might not be
> the same ones who can verify the Gallacian translation, and those who
> understand the details of the LICENSE requirements might not have
> access to a 64-bit Linux machine to test that install. So we need to
> rely on others.
>
> So, a +1 to me means three things:
>
> 1) I have verified what I can verify and it looks acceptable for a release.
>
> 2) No one else has reported a credible, substantial issue with the RC.
>
> 3) I believe that there has been sufficient overall review of the RC.
>
> So obviously my vote can change based on what others find and report
> about the RC. In particular I plan to test a few install scenarios
> and if they work out, I'll vote +1 later today. But if someone later
> finds a serious issue, then I could change my vote.
There are two types of artifacts in the release candidate.
(A) The source release. This is the official package and what the VOTE is ultimately about.
(B) Built installation binaries. These are for user's convenience and are not "official". This includes the SDK.
The SDK and Binaries are missing the DISCLAIMER file. Is a missing Incubation DISCLAIMER in a binary package enough to prevent release? I think probably not, but this may be an edge case. The application pop-ups do mention "Incubation" and every page linked back to the www.openoffice.org shows the Disclaimer...
One approach would be to move forward with AOO 3.4 and plan a AOO 3.4.1 (3.5) in a couple months to clean up all these technical loose ends in advance of Graduation?
My next steps for my VOTE will be to review the Source Release, Build, and RAT scans with spot testing the excludes.
Regards,
Dave
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Rob Weir <ro...@apache.org>.
On Sat, Apr 21, 2012 at 7:21 PM, Kay Schenk <ka...@gmail.com> wrote:
>
>
<snip>
> 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.
>
You are not required to build the AOO RC in order to vote. Remember,
participating in the review and approval of releases is one of the
most basic responsibilities of *all* PMC members. We have selected
PMC members with a wide range of relevant skills, not all of them are
coders. So not everyone is expected to build. But I would expect
that everyone who votes will find something that they can do to help
verify the RC. For example, installing, verifying a translation,
reviewing the LICENSE and NOTICE file, reviewing the RAT scan output,
etc.
Remember, unlike a much smaller project at Apache, we cannot assume
that there is even a single person who understands all aspects of the
product. Not even one. Those who can build on Windows might not be
the same ones who can verify the Gallacian translation, and those who
understand the details of the LICENSE requirements might not have
access to a 64-bit Linux machine to test that install. So we need to
rely on others.
So, a +1 to me means three things:
1) I have verified what I can verify and it looks acceptable for a release.
2) No one else has reported a credible, substantial issue with the RC.
3) I believe that there has been sufficient overall review of the RC.
So obviously my vote can change based on what others find and report
about the RC. In particular I plan to test a few install scenarios
and if they work out, I'll vote +1 later today. But if someone later
finds a serious issue, then I could change my vote.
-Rob
Re: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by Kay Schenk <ka...@gmail.com>.
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:
>
> PARTICIPATE IN QUALITY-ASSURANCE COVERAGE OF THE CANDIDATE
>
> 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 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).
>
> [ ... ]
>
--
------------------------------------------------------------------------
MzK
"Women and cats will do as they please,
and men and dogs should relax and get used to the idea."
-- Robert Heinlein
RE: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
Posted by "Dennis E. Hamilton" <or...@apache.org>.
My oversight:
There is a consolidated link to all of the QA locations for the Release Candidate at
<http://wiki.services.openoffice.org/wiki/Quality_Assurance#Apache_OpenOffice_3.4>.
-----Original Message-----
From: Dennis E. Hamilton [mailto:orcmid@apache.org]
Sent: Saturday, April 21, 2012 13:01
To: ooo-dev@incubator.apache.org
Cc: 'xia zhao'; ooo-qa@incubator.apache.org
Subject: [DISCUSS][VOTE] Release Apache OpenOffice 3.4 (incubating) RC1
[ ... ]
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
[ ... ]