Am 19.04.2012 11:57, schrieb Rob Weir: > 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".
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:[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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >
