incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Jopp <j...@gmx.de>
Subject Re: Has the AOO 3.4 RC been released?
Date Thu, 19 Apr 2012 07:10:24 GMT


Am 19.04.2012 08:19, schrieb Rob Weir:
> On Thu, Apr 19, 2012 at 12:39 AM, Christoph Jopp <jopp@gmx.de> wrote:
>>
>>
>> Am 18.04.2012 23:01, schrieb Rob Weir:
>>> On Wed, Apr 18, 2012 at 7:38 PM, Christoph Jopp <jopp@gmx.de> wrote:
>>>>
>>>>
>>>> Am 18.04.2012 19:17, schrieb Kay Schenk:
>>>>> On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir <robweir@apache.org>
wrote:
>>>>>
>>>>>> On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton
>>>>>> <dennis.hamilton@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.
> 
> In other words, mainly Sun employees.

No, that cuts the long story too short.
Concerning the vcs this might be true, but the dev-snapshots served a
larger audience,
Many extension authors f.e. used them to test their extensions and in
reverse also the office.

> 
>> 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.
>>
> 
> So, in my opinion, only one of these is really "QA".  If you are not
> following a test plan and coordinating with others to maximize test
> coverage and reduce overlap, then you are not really doing QA.  If you
> are not specifically targeting the areas of the code that have been
> changed, then it is not really QA.

That might be a point of philosophy or just one of wording. You can name
the one QA and the other bug hunting.

> 
> It is the difference between what an editor does when editing a book
> versus what a reader does when reading a book.  You can't replace an
> editor with a large number of casual readers. And you can't replace QA
> with a large number of casual users of a build.

No, of course not. But it's not XOR.
And there are for sure many publications out there, that would be better
if they were skimmed through by more people - in addition to an editor.

> 
> Of course,I would not discourage use of dev snapshots, and submitting
> bug reports based on that.  But it does not replace a disciplined QA
> effort. It sounds like that was mainly internal at Sun. We need to
> reform that effort at Apache.   That is what Lily was trying to do,
> but was pretty much ignored.
> 
>> 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.
>>
> 
> That is correct.
> 
>> Anybody feel free to correct me.
>>
>>
>>
>>>
>>> -Rob
>>>
>>>> Is this correct?
>>>>
>>>> Christoph
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> -Rob
>>>>>>
>>>>>>>  - Dennis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Michael Acevedo [mailto:vea1083@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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
> 

Mime
View raw message