Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index

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

First of all, this is what we currently have:



* the testtool (similar to


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

What do you think?

I'll put here a short draft of my dreams if I think of an efficient

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.


Ansprechpartner / contact person for the "PrOOo-Box"
german language "best Office Suite ever" and more on CD/DVD  -- footer changed on 2010-10-07

To unsubscribe, send an empty e-mail to
All messages you send to this list will be publicly archived and cannot be deleted.
List archives are available at


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.