Re: [tdf-discuss] QA Infrastructure

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 <
> damokles4-listen@bits-fritz.de> 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 discuss+unsubscribe@documentfoundation.org
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/