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 10:22:47 GMT


Am 19.04.2012 11:57, schrieb Rob Weir:
> On Thu, Apr 19, 2012 at 11:42 AM, Christoph Jopp <jopp@gmx.de> wrote:
>>
>>
>> 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.
>>
> 
> That's fine.  And from our discussions on this it sounds like bug
> hunting, if done with data collection and feedback, can give some of
> the same advantages of a more formal approach.   It would be
> interesting to explore how to to "get the best of both worlds".

Yes, for sure and I saw you and Andre have already some interesting ideas.

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