incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Has the AOO 3.4 RC been released?
Date Thu, 19 Apr 2012 09:57:29 GMT
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".

>



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