Re: Has the AOO 3.4 RC been released?
On Thu, Apr 19, 2012 at 12:39 AM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 23:01, schrieb Rob Weir: On Wed, Apr 18, 2012 at 7:38 PM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir robw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a candidate. Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. So all that can be checked for bugs and regressions are the unofficial snapshots. Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this. However, to the extent we want to take an engineering-informed approach to QA, and make optimal use of volunteer time, and use this effort in a way that best improves product quality, then we want to be testing much earlier in the project cycle. That is why Lily sent several notes
Re: Has the AOO 3.4 RC been released?
Am 19.04.2012 08:19, schrieb Rob Weir: On Thu, Apr 19, 2012 at 12:39 AM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 23:01, schrieb Rob Weir: On Wed, Apr 18, 2012 at 7:38 PM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir robw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a candidate. Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. So all that can be checked for bugs and regressions are the unofficial snapshots. Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this. However, to the extent we want to take an engineering-informed approach to QA, and make optimal use of volunteer time, and use this effort in a way that best improves product quality, then we want to be testing much earlier in the project
Re: Has the AOO 3.4 RC been released?
On 19.04.2012 17:08, Rob Weir wrote: On Thu, Apr 19, 2012 at 9:10 AM, Christoph Joppj...@gmx.de wrote: Am 19.04.2012 08:19, schrieb Rob Weir: On Thu, Apr 19, 2012 at 12:39 AM, Christoph Joppj...@gmx.de wrote: Am 18.04.2012 23:01, schrieb Rob Weir: On Wed, Apr 18, 2012 at 7:38 PM, Christoph Joppj...@gmx.de wrote: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weirrobw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a candidate. Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. So all that can be checked for bugs and regressions are the unofficial snapshots. Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this. However, to the extent we want to take an engineering-informed approach to QA, and make optimal use of volunteer time, and use this effort in a way that best improves product quality, then we want
Re: Has the AOO 3.4 RC been released?
On Thu, Apr 19, 2012 at 11:19 AM, Andre Fischer a...@a-w-f.de wrote: On 19.04.2012 17:08, Rob Weir wrote: On Thu, Apr 19, 2012 at 9:10 AM, Christoph Joppj...@gmx.de wrote: Am 19.04.2012 08:19, schrieb Rob Weir: On Thu, Apr 19, 2012 at 12:39 AM, Christoph Joppj...@gmx.de wrote: Am 18.04.2012 23:01, schrieb Rob Weir: On Wed, Apr 18, 2012 at 7:38 PM, Christoph Joppj...@gmx.de wrote: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weirrobw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a candidate. Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. So all that can be checked for bugs and regressions are the unofficial snapshots. Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this. However, to the extent we want to
Re: Has the AOO 3.4 RC been released?
On 19.04.2012 17:32, Rob Weir wrote: On Thu, Apr 19, 2012 at 11:19 AM, Andre Fischera...@a-w-f.de wrote: On 19.04.2012 17:08, Rob Weir wrote: On Thu, Apr 19, 2012 at 9:10 AM, Christoph Joppj...@gmx.dewrote: Am 19.04.2012 08:19, schrieb Rob Weir: On Thu, Apr 19, 2012 at 12:39 AM, Christoph Joppj...@gmx.dewrote: Am 18.04.2012 23:01, schrieb Rob Weir: On Wed, Apr 18, 2012 at 7:38 PM, Christoph Joppj...@gmx.dewrote: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weirrobw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.orgwrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a candidate. Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. So all that can be checked for bugs and regressions are the unofficial snapshots. Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this. However, to the extent we want to take an engineering-informed
Re: Has the AOO 3.4 RC been released?
Am 19.04.2012 11:08, schrieb Rob Weir: On Thu, Apr 19, 2012 at 9:10 AM, Christoph Jopp j...@gmx.de wrote: Am 19.04.2012 08:19, schrieb Rob Weir: On Thu, Apr 19, 2012 at 12:39 AM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 23:01, schrieb Rob Weir: On Wed, Apr 18, 2012 at 7:38 PM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir robw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a candidate. Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. So all that can be checked for bugs and regressions are the unofficial snapshots. Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this. However, to the extent we want to take an engineering-informed approach to QA, and make optimal use of volunteer time,
Re: Has the AOO 3.4 RC been released?
On Thu, Apr 19, 2012 at 11:42 AM, Christoph Jopp j...@gmx.de wrote: Am 19.04.2012 11:08, schrieb Rob Weir: On Thu, Apr 19, 2012 at 9:10 AM, Christoph Jopp j...@gmx.de wrote: Am 19.04.2012 08:19, schrieb Rob Weir: On Thu, Apr 19, 2012 at 12:39 AM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 23:01, schrieb Rob Weir: On Wed, Apr 18, 2012 at 7:38 PM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir robw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a candidate. Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. So all that can be checked for bugs and regressions are the unofficial snapshots. Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this. However, to the extent we want to take an
Re: Has the AOO 3.4 RC been released?
Am 19.04.2012 11:57, schrieb Rob Weir: On Thu, Apr 19, 2012 at 11:42 AM, Christoph Jopp j...@gmx.de wrote: Am 19.04.2012 11:08, schrieb Rob Weir: On Thu, Apr 19, 2012 at 9:10 AM, Christoph Jopp j...@gmx.de wrote: Am 19.04.2012 08:19, schrieb Rob Weir: On Thu, Apr 19, 2012 at 12:39 AM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 23:01, schrieb Rob Weir: On Wed, Apr 18, 2012 at 7:38 PM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir robw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a candidate. Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. So all that can be checked for bugs and regressions are the unofficial snapshots. Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this.
Re: Has the AOO 3.4 RC been released?
On 19/04/2012 Christoph Jopp wrote: Plus, I think you will find more people to take part in bug hunting (fun) than doing disciplined QA (work). Not necessarily. Contrary to what people might think, the community QA activities have traditionally been very structured: each volunteer received a few dozens very specific tests to run and reported the results back. We're following the same pattern for the ongoing community tests on the Italian version, by assigning each volunteer specific categories of tests from the wiki page. Then of course volunteers are still volunteers and you can't demand that they do their tests and respect deadlines, but this method was quite effective so far. Regards, Andrea.
Re: Has the AOO 3.4 RC been released?
There still seems to be a misunderstanding. Am 19.04.2012 14:44, schrieb Andrea Pescetti: On 19/04/2012 Christoph Jopp wrote: Plus, I think you will find more people to take part in bug hunting (fun) than doing disciplined QA (work). Not necessarily. Contrary to what people might think, the community QA activities have traditionally been very structured: each volunteer received a few dozens very specific tests to run and reported the results back. We're following the same pattern for the ongoing community tests on the Italian version, by assigning each volunteer specific categories of tests from the wiki page. I know that there was done really good QA work by the OpenOffice.org QA community and not only by SUN employees. I also agree that this kind of work really has to be done and it would be really cool to have a similar strong QA community in the Apache project. I also found it big news, when you said there are around 20 people doing this for the Italian version. The other thing was that with announcing and publishing Beta Versions and Release Candidates also people without a close connection to the project were attracted to test or maybe better to try out the new version. And their bug hunting might be of some value. Then of course volunteers are still volunteers and you can't demand that they do their tests and respect deadlines, but this method was quite effective so far. Regards, Andrea.
Re: Has the AOO 3.4 RC been released?
Christoph Jopp wrote: There still seems to be a misunderstanding. ... The other thing was that with announcing and publishing Beta Versions and Release Candidates also people without a close connection to the project were attracted to test or maybe better to try out the new version. And their bug hunting might be of some value. Yes, sure. While we encourage volunteers to help in an organized way, brave users or bug hunters are welcome too. The main problem I see is to provide them with a clear channel for bug reporting/triaging: some of them will report bugs on a mailing list, but won't bother filing a Bugzilla issue. For localized QA the localized mailing lists could do the job, for general QA would it make sense to refer users to the newly created QA list? (Of course the best solution would be to have everybody file their issues properly in Bugzilla, but we can't expect this from everybody). Regards, Andrea
Re: Has the AOO 3.4 RC been released?
On Thu, Apr 19, 2012 at 10:28 PM, Andrea Pescetti pesce...@apache.org wrote: Christoph Jopp wrote: There still seems to be a misunderstanding. ... The other thing was that with announcing and publishing Beta Versions and Release Candidates also people without a close connection to the project were attracted to test or maybe better to try out the new version. And their bug hunting might be of some value. Yes, sure. While we encourage volunteers to help in an organized way, brave users or bug hunters are welcome too. The main problem I see is to provide them with a clear channel for bug reporting/triaging: some of them will report bugs on a mailing list, but won't bother filing a Bugzilla issue. For localized QA the localized mailing lists could do the job, for general QA would it make sense to refer users to the newly created QA list? (Of course the best solution would be to have everybody file their issues properly in Bugzilla, but we can't expect this from everybody). Or is there something we can do to make BZ bug reporting easier? QA list is definitely *not* for reporting bugs. Maybe ooo-users? -Rob Regards, Andrea
Re: Has the AOO 3.4 RC been released?
On Thu, 2012-04-19 at 23:06 +0200, Rob Weir wrote: On Thu, Apr 19, 2012 at 10:28 PM, Andrea Pescetti pesce...@apache.org wrote: Christoph Jopp wrote: There still seems to be a misunderstanding. ... The other thing was that with announcing and publishing Beta Versions and Release Candidates also people without a close connection to the project were attracted to test or maybe better to try out the new version. And their bug hunting might be of some value. Yes, sure. While we encourage volunteers to help in an organized way, brave users or bug hunters are welcome too. The main problem I see is to provide them with a clear channel for bug reporting/triaging: some of them will report bugs on a mailing list, but won't bother filing a Bugzilla issue. For localized QA the localized mailing lists could do the job, for general QA would it make sense to refer users to the newly created QA list? (Of course the best solution would be to have everybody file their issues properly in Bugzilla, but we can't expect this from everybody). Howdy, Or is there something we can do to make BZ bug reporting easier? Certainly.. different message thread, I think, but I like web forms. Any volunteers? QA list is definitely *not* for reporting bugs. Maybe ooo-users? I'd agree, though I would encourage those folks directly active with user communication (on the different user ML/Forums) to subscribe to it, so that information does get out efficiently. For right now, for myself, I ran across the wiki page: http://wiki.services.openoffice.org/wiki/QA That's gotta get fixed - I'll work on this tonight, the support page and docs page on the main site also, can't be put off longer, if others start great but either way I'll try start on those here directly, also. //drew -Rob Regards, Andrea
[QA Wiki page update]Re: Has the AOO 3.4 RC been released?
snip QA list is definitely *not* for reporting bugs. Maybe ooo-users? I'd agree, though I would encourage those folks directly active with user communication (on the different user ML/Forums) to subscribe to it, so that information does get out efficiently. For right now, for myself, I ran across the wiki page: http://wiki.services.openoffice.org/wiki/QA made changes to the above wiki page. Added a link to this page http://www.openoffice.org/qa/issue_handling/submission_gateway.html#application which now adds an item for fixing (the rest of the page seems to work but)..the search box leads to a dead link at http://www.openoffice.org/bugzilla/buglist.cgi?quicksearch=criteria //drew snip
Re: Has the AOO 3.4 RC been released?
On Wed, Apr 18, 2012 at 2:02 AM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Is there any reason why the developer snapshots, r1325589, the same files as currently linked as RC1 candidates, can't simply be used under the condition that they are not yet releases but are essentially feature-frozen and stable (but for any last-minute show-stopper bugs)? They should not be redistributed or placed in product yet, of course. Dennis, this has been true for dev snapshots for the last month now. Many of us have been using them in our daily work. I.e., aren't these worthy of QA and exercising as suitable for upgrading of OpenOffice.org 3.3.0: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots? Ditto for QA. That's where the bug reports have come from -- people using the dev snapshots. -Rob - Dennis -Original Message- From: Jürgen Schmidt [mailto:jogischm...@googlemail.com] Sent: Tuesday, April 17, 2012 16:32 To: ooo-dev@incubator.apache.org Subject: Re: Has the AOO 3.4 RC been released? On 4/17/12 8:35 PM, Michael Acevedo wrote: Hi, I was wondering if the AOO 3.4 Release Candidate is now available for download? I see an entry in the Wiki that says so. Many Thanks The RC will be announced here on the list at least. The wiki was prepared already but we have found a further issue with a placeholder in the NOTICE file. Juergen
RE: Has the AOO 3.4 RC been released?
Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? - Dennis -Original Message- From: Michael Acevedo [mailto:vea1...@gmail.com] Sent: Tuesday, April 17, 2012 11:36 To: Apache OpenOffice Subject: Has the AOO 3.4 RC been released? Hi, I was wondering if the AOO 3.4 Release Candidate is now available for download? I see an entry in the Wiki that says so. Many Thanks -- Best, Michael
Re: Has the AOO 3.4 RC been released?
On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. -Rob - Dennis -Original Message- From: Michael Acevedo [mailto:vea1...@gmail.com] Sent: Tuesday, April 17, 2012 11:36 To: Apache OpenOffice Subject: Has the AOO 3.4 RC been released? Hi, I was wondering if the AOO 3.4 Release Candidate is now available for download? I see an entry in the Wiki that says so. Many Thanks -- Best, Michael
Re: Has the AOO 3.4 RC been released?
On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir robw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. -Rob - Dennis -Original Message- From: Michael Acevedo [mailto:vea1...@gmail.com] Sent: Tuesday, April 17, 2012 11:36 To: Apache OpenOffice Subject: Has the AOO 3.4 RC been released? Hi, I was wondering if the AOO 3.4 Release Candidate is now available for download? I see an entry in the Wiki that says so. Many Thanks -- Best, Michael -- MzK Women and cats will do as they please, and men and dogs should relax and get used to the idea. -- Robert Heinlein
Re: Has the AOO 3.4 RC been released?
Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir robw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. So all that can be checked for bugs and regressions are the unofficial snapshots. Is this correct? Christoph -Rob - Dennis -Original Message- From: Michael Acevedo [mailto:vea1...@gmail.com] Sent: Tuesday, April 17, 2012 11:36 To: Apache OpenOffice Subject: Has the AOO 3.4 RC been released? Hi, I was wondering if the AOO 3.4 Release Candidate is now available for download? I see an entry in the Wiki that says so. Many Thanks -- Best, Michael
Re: Has the AOO 3.4 RC been released?
Am 18.04.2012 19:38, schrieb Christoph Jopp: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir robw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. So all that can be checked for bugs and regressions are the unofficial snapshots. Maybe, to be more clear: I think (and still might be wrong) if we would like to have a public RC/Beta/whatsoever we had to reach out to the Incubator Project (our Mentors?). But I think this wasn't done before by a podling and means extra effort for the Incubator. Is this correct? Christoph -Rob - Dennis -Original Message- From: Michael Acevedo [mailto:vea1...@gmail.com] Sent: Tuesday, April 17, 2012 11:36 To: Apache OpenOffice Subject: Has the AOO 3.4 RC been released? Hi, I was wondering if the AOO 3.4 Release Candidate is now available for download? I see an entry in the Wiki that says so. Many Thanks -- Best, Michael
Re: Has the AOO 3.4 RC been released?
Hi, when providing an OOo snapshot as a release candidate binaries were signed. Will this be the case with the first RC provided for AOO ? Kind regards, Joost
Re: Has the AOO 3.4 RC been released?
On Wed, Apr 18, 2012 at 7:38 PM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir robw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a candidate. Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. So all that can be checked for bugs and regressions are the unofficial snapshots. Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this. However, to the extent we want to take an engineering-informed approach to QA, and make optimal use of volunteer time, and use this effort in a way that best improves product quality, then we want to be testing much earlier in the project cycle. That is why Lily sent several notes to the list, months ago, asking for help testing AOO dev snapshots. I don't think anyone offered to help, despite these several requests :-(
Re: Has the AOO 3.4 RC been released?
Am 18.04.2012 23:01, schrieb Rob Weir: On Wed, Apr 18, 2012 at 7:38 PM, Christoph Jopp j...@gmx.de wrote: Am 18.04.2012 19:17, schrieb Kay Schenk: On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir robw...@apache.org wrote: On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Michael, I am curious what has you be interested in the availability of an AOO 3.4 Release Candidate. 1. What does it say to you when a project build set is designated a Release Candidate? 2. What use would you make of such a designated build different from a developer snapshot and an actual release (i.e., AOO 3.4[.0])? I wonder if there might be some language misunderstanding when we say casually, We'll soon be voting on a Release Candidate? To some this could mean we will have a vote to label a particular build as a Release Candidate. That interpretation would explain some of the post we've been seeing. But that is not how it really works. What actually happens is two things: 1) The Release Manager (Juergen) declares that a particular build is the Release Candidate. 2) The PMC then votes on whether or not to release the Release Candidate. When we say vote on a Release Candidate, some readers might think that we're voting to make the Release Candidate. But we're really voting to release the Release Candidate. Like when I vote for candidate for US President, I'm not voting to make him a candidate. I'm voting to make him President. A further point of clarification. Does Release Candidate in the ASF have the same meaning as the traditional meaning. See, for example: http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate Given this definition, a Release Candidate means the final test before the actual release. So, to me, and perhaps others, a release candidate is NOT the same as a release. And, to me, a release candidate as opposed to a release implies some predetermined time announced to the public at large, for FINAL testing -- seems like 2 weeks is typical. I am not sure at this point if this historical definition applies in the ASF. I think it would be valuable to head up a new thread on this -- What it means to vote on a release candidate at the ASF -- or something similar so folks have a better understanding of release candidates/release at the ASF. I might be totally wrong, but I think the main difference is that this project as long as it is a podling does not release anything. The one who releases is the Incubator project and the podling (PPMC) presents (after voting) the Incubator project a candidate to be released. Then the Incubator project votes whether it should be officially released or not. The PPMC votes to approve the Release Candidate as suitable for release. The IPMC, which has the overall responsibility for ensuring that all podling releases conform to Apache policies, then votes on whether the release can actually occur. But this is not why we call it a candidate. Even once we graduate to be a Top Level Project (TLP) and vote on our own release, we would still call this stage a Release Candidate. I have no idea how the project did testing before, but the approach I learned was to match the risk with the test effort. So after major code changes you have a major test effort. And when code changes are minor, then you have less testing. And when there are almost no coding changes, like when simply updating the NOTICE.txt file, then you have only the smallest test effort. As we get closer to a release we reduce the rate of change in the code, but also reduce the testing effort. So releasing code is like pulling a trigger on a rifle, slow and smooth, not a sudden jerky motion. The major coding effort for AOO 3.4 was the removal/replacement of copyleft components with compatibly licensed components. That work was completed last year. That was what needed most of the test effort, and that testing was already done. The product changes in recent weeks have been very minor, generally around packaging the language translations and dictionaries. So it should be sufficient to concentrate the scope of testing to what has changed. That doesn't mean that a volunteer is not permitted to go back and test code that has not changed in 6 months. But it would not be an optimal use of their time. So all that can be checked for bugs and regressions are the unofficial snapshots. Volunteers are welcome to check any build or release candidate for any bugs at any time and enter them into BZ. There are no restrictions on this. However, to the extent we want to take an engineering-informed approach to QA, and make optimal use of volunteer time, and use this effort in a way that best improves product quality, then we want to be testing much earlier in the project cycle. That is why Lily sent several notes to the list, months ago, asking for help testing AOO dev
Re: Has the AOO 3.4 RC been released?
Rob Weir: we want to be testing much earlier in the project cycle. That is why Lily sent several notes to the list, months ago, asking for help testing AOO dev snapshots. I don't think anyone offered to help, despite these several requests :-( Around 20 volunteers from the Italian community are now testing the RC1; bugs will be reported in BugZilla, possible release stoppers discussed here. It is extremely easier to get volunteers to test a release at this (late) stage than in any earlier moment, people are much more motivated when a release is approaching. We are basing our tests on the Italian translation/adaptation of http://wiki.services.openoffice.org/wiki/QA/TestCases/ Regards, Andrea.
Re: Has the AOO 3.4 RC been released?
On 04/18/2012 03:51 PM, Andrea Pescetti wrote: Rob Weir: we want to be testing much earlier in the project cycle. That is why Lily sent several notes to the list, months ago, asking for help testing AOO dev snapshots. I don't think anyone offered to help, despite these several requests :-( Is this really true? I was under the impression folks had been downloading and testing for at least a month or so now when requests came up or new developer versions became available. I think maybe folks HAVE been downloading but not giving any formal feedback in direct response to (specifically) Lily's request. Maybe posts to ooo-users and/or ooo-announcements would help? Around 20 volunteers from the Italian community are now testing the RC1; bugs will be reported in BugZilla, possible release stoppers discussed here. It is extremely easier to get volunteers to test a release at this (late) stage than in any earlier moment, people are much more motivated when a release is approaching. We are basing our tests on the Italian translation/adaptation of http://wiki.services.openoffice.org/wiki/QA/TestCases/ Regards, Andrea. -- MzK Women and cats will do as they please, and men and dogs should relax and get used to the idea. -- Robert Heinlein
Re: Has the AOO 3.4 RC been released?
On 4/18/12 10:16 PM, Joost Andrae wrote: Hi, when providing an OOo snapshot as a release candidate binaries were signed. Will this be the case with the first RC provided for AOO ? Kind regards, Joost when you mean if we can sign the windows binary with an official Apache certificate to avoid warning message during the installation etc. then no. This is an open topic where I have asked questions on the list and asked for advice from our mentors how to proceed. Maybe I have overseen something but we have no answer yet. I will focus on a clarification asap when I have the time for it becasue it is important. A signed binary (not the already provided signing of the download packages)) will increase the trust in our project, organization etc. It should be of high interest for Apache as well. Juergen
Re: Has the AOO 3.4 RC been released?
I don't think anyone offered to help, despite these several requests :-( I think that it has slipped your attention that I've made lot of tests with the old vcl testtool. Groetjes, Olaf
Re: Has the AOO 3.4 RC been released?
On 4/17/12 8:35 PM, Michael Acevedo wrote: Hi, I was wondering if the AOO 3.4 Release Candidate is now available for download? I see an entry in the Wiki that says so. Many Thanks The RC will be announced here on the list at least. The wiki was prepared already but we have found a further issue with a placeholder in the NOTICE file. Juergen
RE: Has the AOO 3.4 RC been released?
Is there any reason why the developer snapshots, r1325589, the same files as currently linked as RC1 candidates, can't simply be used under the condition that they are not yet releases but are essentially feature-frozen and stable (but for any last-minute show-stopper bugs)? They should not be redistributed or placed in product yet, of course. I.e., aren't these worthy of QA and exercising as suitable for upgrading of OpenOffice.org 3.3.0: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots? - Dennis -Original Message- From: Jürgen Schmidt [mailto:jogischm...@googlemail.com] Sent: Tuesday, April 17, 2012 16:32 To: ooo-dev@incubator.apache.org Subject: Re: Has the AOO 3.4 RC been released? On 4/17/12 8:35 PM, Michael Acevedo wrote: Hi, I was wondering if the AOO 3.4 Release Candidate is now available for download? I see an entry in the Wiki that says so. Many Thanks The RC will be announced here on the list at least. The wiki was prepared already but we have found a further issue with a placeholder in the NOTICE file. Juergen
Re: Has the AOO 3.4 RC been released?
None really, it all depends how close to the bleeding edge you or your company is willing to be. License compliance may be important to a company... Regards, Dave Sent from my iPhone On Apr 17, 2012, at 5:02 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Is there any reason why the developer snapshots, r1325589, the same files as currently linked as RC1 candidates, can't simply be used under the condition that they are not yet releases but are essentially feature-frozen and stable (but for any last-minute show-stopper bugs)? They should not be redistributed or placed in product yet, of course. I.e., aren't these worthy of QA and exercising as suitable for upgrading of OpenOffice.org 3.3.0: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots? - Dennis -Original Message- From: Jürgen Schmidt [mailto:jogischm...@googlemail.com] Sent: Tuesday, April 17, 2012 16:32 To: ooo-dev@incubator.apache.org Subject: Re: Has the AOO 3.4 RC been released? On 4/17/12 8:35 PM, Michael Acevedo wrote: Hi, I was wondering if the AOO 3.4 Release Candidate is now available for download? I see an entry in the Wiki that says so. Many Thanks The RC will be announced here on the list at least. The wiki was prepared already but we have found a further issue with a placeholder in the NOTICE file. Juergen
Re: Has the AOO 3.4 RC been released?
On 4/18/12 2:02 AM, Dennis E. Hamilton wrote: Is there any reason why the developer snapshots, r1325589, the same files as currently linked as RC1 candidates, can't simply be used under the condition that they are not yet releases but are essentially feature-frozen and stable (but for any last-minute show-stopper bugs)? They should not be redistributed or placed in product yet, of course. I.e., aren't these worthy of QA and exercising as suitable for upgrading of OpenOffice.org 3.3.0:https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots? - Dennis sure, people can use it and can test it in the same way as before. Taking it from this page should make clear that it's adev snapshot. But if people take it from the release candidate wiki the expectation might be different. The reason why we point on the same bits is simply the amount of data that we have to move and to upload. Especially the upload is not always fun. Means mainly practical reasons. Juergen -Original Message- From: Jürgen Schmidt [mailto:jogischm...@googlemail.com] Sent: Tuesday, April 17, 2012 16:32 To: ooo-dev@incubator.apache.org Subject: Re: Has the AOO 3.4 RC been released? On 4/17/12 8:35 PM, Michael Acevedo wrote: Hi, I was wondering if the AOO 3.4 Release Candidate is now available for download? I see an entry in the Wiki that says so. Many Thanks The RC will be announced here on the list at least. The wiki was prepared already but we have found a further issue with a placeholder in the NOTICE file. Juergen
