Hi Nguyen Vu Hung, *, hope this is the correct appellation..
first of all: I'm not involved in Software development and neither in QA *therefore* I'm answering here. :o)) Nguyen Vu Hung schrieb: >On Thu, Oct 7, 2010 at 9:58 PM, Friedrich Strohmaier < >[email protected]> wrote: >> Thorsten Behrens schrieb: >> >as we start to ramp up more infrastructure, I'd like to make >> >you think about what's crucially needed to do QA for LibreOffice >> >3.3. >> >First of all, this is what we currently have: >> <stretched> [..] >> > * the testtool (similar to OpenOffice.org) >> </stretched> >Do you mean VCLTestool - used for automated testing in LibO? >Do we need a (VCLTesttool-used) test server? and >Do we need a build server like Java Huson? >That would be a big help (for QA members) Shure? Maybe it's a great tool for developers but if it is a great tool for QA members isn't proven yet. [..] >> >I know that the OpenOffice.org QA project has things like QATrack, >> >QUASTe, and TCM - but I wonder which of those pass the test of "we >> >really need it, and it's worth the effort to duplicate it/set it >> >up". >> >What do you think? >> I'll put here a short draft of my dreams if I think of an efficient >> QA >> I think of three states the software idally should pass: >> 1. The most recent developer build (nightly builds). >The build takes days, so I would like weekly buids. Even if actually reality. What I *like* were nightly builds! remember: It's a dream and I'm not a developer :o)) >> 2. an "alive" release lets call it "LibO - fresh" which passed a >> quite short beta period for early adopters, experienced users, and >> "new features greedy" ones. >I thought our developers would work on git/svn branches so we have lots >of builds (like that way Linux kernel hackers do) I freely admit: I don't understand what You are talking about.. >All the branches can combined as a "fresh" realease (.i.e. unstable) >Combined works on the branches those are targeted for official > releases, we will have RC1, RC2... versions. As far as I see those RCs are made to ensure the release which will last long time (i.e. 6 months) to keep free of bugs. I can't see that anyone succeded that except microsoft. ;o)) I'd prefer to face reality of the (outer microsoft) world and have the RCs substituted by nightly builds with fixed bugs - even that ones appearing *after* releasing the last RC. >This staging strategy will improve the quality of LibO - I hope. I am with You! :o)) >> 3. a "mature" release which has passed ~6 months "fresh" state. >> Question: How do us determine LibO's realease cycle. >I want it to be as short as possible (6 months?) Fits that the requirements of an office environment? I'm not shure. Gruß/regards -- Friedrich Ansprechpartner / contact person for the "PrOOo-Box" german language "best Office Suite ever" and more on CD/DVD http://prooo-box.org -- footer changed on 2010-10-07 -- To unsubscribe, send an empty e-mail to [email protected] All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/
