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
> snapshots.  I don't think anyone offered to help, despite these
> several requests :-(

Just to make one thing clear upfront: I didn't want to criticize the old
or the new process of testing and releasing.
As many people seemed to be confused about the naming, I tried to
explain - and failed.

I'll try again and maybe fail again.
I think the confusion comes from the different process in the old project.

The old process, as I see it (some other people might know better) was
somewhat tiered:
The source in the version control system was only touched by some core
developers. From time to time a developer snapshot was made available
for people not able or willing to build from source. But these
dev-snapshots were largely used by people with high affinity to the
project and/or technical understanding.
I think some mirrors did not distribute dev-snapshots.

"Internal" QA was done perpetually.

Then Beta-Releases and Release Candidates were announced and published
to a bigger community including users with less or no "technical"
understanding to test and report.

And so I think some people are waiting for the announcement of a
"Release Candidate" published through the mirror system for final
testing through the greater community.
And I just wanted to say that the procedure has changed and I think a
Release Candidate in the above sense would not come.

Anybody feel free to correct me.



> 
> -Rob
> 
>> 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
>>>>>
>>>>
>>>
>>>
>>>
> 

Reply via email to