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