On Thu, Apr 19, 2012 at 11:42 AM, Christoph Jopp <[email protected]> wrote: > > > 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. >
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:[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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >>
