incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer ...@a-w-f.de>
Subject Re: Has the AOO 3.4 RC been released?
Date Thu, 19 Apr 2012 09:42:10 GMT
On 19.04.2012 17:32, Rob Weir wrote:
> On Thu, Apr 19, 2012 at 11:19 AM, Andre Fischer<af@a-w-f.de>  wrote:
>> On 19.04.2012 17:08, Rob Weir wrote:
>>>
>>> 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.
>>
>>
>> But it could also be viewed as application of the Monte Carlo method that,
>> among other things, is not so prone to systematic errors.
>>
>
> If bug hunters were truly random, then that might work.  Not very
> efficient, but at least it would eventually give you complete
> coverage.  But if done casually you end up with most people testing
> the same basic functions over and over again, without getting much
> depth.  So it is not random.

Of course.

>
> Even a little coordination and structure can improve this.  For
> example, if we had a wiki page where we listed all functional areas,
> or features or menu items, or even a matrix of platforms and asked
> "bug hunters" to indicate which areas they have explored.  If we did
> that at least we'd know what areas were under-tested and could avoid
> over-testing the same basic areas.
>
> Maybe even have a test mode in the product that tracks what areas are
> exercised?   Not code coverage at the fine grained level, but
> something at a higher feature level.

That sounds like a good idea.  Maybe add some color coding for UI 
elements that tells the tester which parts need more testing (have not 
been clicked on so often).  We actually had something like this for 
analysis of user feedback that told us how often a button or menu entry 
had been clicked.  The visualization was done, of course, in a 
post-processing step.

>
>> I think that both approaches have their advantages and that both should be
>> used.
>>
>> -Andre
>>
>>
>>>
>>>>>
>>>>> 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.
>>>
>>> -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