Am 19.04.2012 11:08, schrieb Rob Weir: > On Thu, Apr 19, 2012 at 9:10 AM, Christoph Jopp <[email protected]> wrote: >> >> >> Am 19.04.2012 08:19, schrieb Rob Weir: >>> On Thu, Apr 19, 2012 at 12:39 AM, Christoph Jopp <[email protected]> wrote: >>>> >>>> >>>> Am 18.04.2012 23:01, schrieb Rob Weir: >>>>> On Wed, Apr 18, 2012 at 7:38 PM, Christoph Jopp <[email protected]> wrote: >>>>>> >>>>>> >>>>>> Am 18.04.2012 19:17, schrieb Kay Schenk: >>>>>>> On Wed, Apr 18, 2012 at 9:53 AM, Rob Weir <[email protected]> wrote: >>>>>>> >>>>>>>> On Wed, Apr 18, 2012 at 6:41 PM, Dennis E. Hamilton >>>>>>>> <[email protected]> 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:[email protected]] >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> >
