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 09:42:56 GMT


Am 19.04.2012 11:08, schrieb Rob Weir:
> On Thu, Apr 19, 2012 at 9:10 AM, Christoph Jopp <jopp@gmx.de> wrote:
>>
>>
>> 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.
>>
> 
> I think these are important distinctions.  Suppose a child is lost in
> the woods and you want to find her.  The police will use a methodical,
> coordinated approach, breaking the area into a grid and doing a search
> and rescue operation that aims for maximal coverage with defined
> levels of overlap.    They always know what % of the search area they
> have covered and can estimate when the search will be complete.  If
> more volunteers become available they can deploy the new resources in
> an optimal way.
> 
> Compare that to a random set volunteers, with good intentions, but
> without coordination or a methodology?
> 
> That is the difference between a disciplined QA effort and random "bug
> hunting".  Bug hunters may get lucky.  Quality engineers do not rely
> on luck.

Agreed, but again: I think it's not an "exclusive-or-decision" and ...
(see below)

> 
>>>
>>> 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.
>>
> 
> And maybe even better if they had better editors? ;-)
> 
> In any case, I think this is very important for the project.  It is
> clear, from other related projects, that doing just bug hunting
> without disciplined QA leads to poor quality outcomes, with low user
> satisfaction.  So I think it is very important that we scale up a
> formal QA effort for AOO 4.0.

As stated above: No XOR.
Plus, I think you will find more people to take part in bug hunting
(fun) than doing "disciplined" QA (work). So you'll have at least
additional finds.
Again I'm not pleading for a substitution of one with the other.
On the contrary, some of the people who are doing bug hunting for fun
might get interested in doing work through disciplined QA.


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