Hi Martin,
your proposal is definitely a step into the right direction IMHO.
Since in the past we've often had cases where a fix in one RC caused a
regression in the next one, I'd also like to see the developer's risk
estimation have an effect on whether an issue gets accepted as a
Hi Mechtilde,
Mechtilde schrieb:
Hello thorsten, *
or another example:#
Why is it possible to get a 64 build but no 32 bit build?
Isn't it th same build environment on the buildbots?
Depending on the platform, tools as the compiler may differ, and in this
case even the Ubuntu version
Hi Andre,
Andre Schnabel schrieb:
Hi Thorsten,
Original-Nachricht
Von: Thorsten Ziehm thorsten.zi...@sun.com
where is the problem? (I know I asked this since months and do not get
any detailed answer) :-(
You are correct with this. And I was just going to get builds
Hi,
looking at the mailing-list archives I just saw that there was a
discussion about whether the Solver is useful a few years ago. There
were some pros and cons and some people thought it would be useful and
should still be offered for download. Now theoretically being useful and
being
Hi,
Jens-Heiner Rechtien schrieb:
Martin Hollmichel wrote:
Jens-Heiner Rechtien wrote:
Hi Martin,
since almost all OOO300 CWSs (for the RC) will be integrated into
DEV300 as well it makes sense to have most of them already integrated
into DEV300 before starting the migration. Also there
Hi,
since yesterday evening ~7 pm (GMT+2) the tools are working again.
Regards,
Jörg
Jörg Jahnke schrieb:
Hi,
due to a failure of the internet connection eis.services.openoffice.org
and tools.services.openoffice.org, where the Environment Information
System (EIS) and e.g. the dashboards
Hi,
due to a failure of the internet connection eis.services.openoffice.org
and tools.services.openoffice.org, where the Environment Information
System (EIS) and e.g. the dashboards are hosted, are currently not
available. A technician is expected to arrive within the next hours and
will
Hi,
again a reminder: We are going to have another Release Engineering QA
session tomorrow. The channel will again be #re.openoffice.org, time is
10 am Hamburg time (which is GMT+2) / 4 pm Beijing time. If you have
some agenda item(s), please reply to this mail to add them.
Regards,
Jörg
Hi,
just as a reminder: We are going to have another Release Engineering QA
session tomorrow. The channel will again be #re.openoffice.org, time is
10 am Hamburg time (which is GMT+2) / 4 pm Beijing time. If you have
some agenda item(s), please reply to this mail to add them.
Regards,
Jörg
OK, lets choose #re.openoffice.org.
Jörg
liutao schrieb:
That channel is ok :-)
LiuTao
I think we should go to the channel #oootalk,or it will be very
disorderly
What about #re.openoffice.org? ;-)
--
Pavel Janík
-
To
Hi Mathias,
Mathias Bauer schrieb:
So again: I want to get a good compromise between effort (hours to run)
and result (coverage of code that is known to be prone to regressions).
So before I can agree to any regression testing I must know if this
testing really investigates the parts of the
Hi Mathias,
Mathias Bauer schrieb:
I agree that a good compromise between effort and result should be
found. But you seem to miss the point that the planned tests are not
meant to do Unit Testing but are on a different level of testing, which
is System Testing (up into the area of Integration
.
Additionally the suggestion was made to run a pilot to test the new
regression test handling. This is exactly what we will try to do,
improve the test tool and prepare the test cases, so that we are able to
run a pilot and clarify the above questions.
Regards,
Jörg
Jörg Jahnke schrieb:
Hi
Hi Rene,
Rene Engelhard schrieb:
Or imagine such a test run (failing or not) short before a release,
where you have a small CWS fixing a showstopper only. We don't really
want to have a mandatory 3 day delay in such situations, do we?
Best example currently: cws freetypettg. tiny *security*
Hi Rüdiger,
Rüdiger Timm schrieb:
Jörg Jahnke wrote:
Hi Hennes,
Hennes Rohling schrieb:
...
But don't make everything mandatory. If I change a string in the
setup or change platform dependend code for systemintegration I don't
want to do a mandatory test that tests whether all dialogs
Hi Mathias,
Mathias Bauer schrieb:
Jörg Jahnke wrote:
But I agree that a proper selection of tests is a good idea. Perhaps a
user should be able to call e.g. dmake regressiontests -run:sw,basic
to execute special tests for the writer and the basic.
You misunderstood me. I took
Hi Rüdiger,
Rüdiger Timm schrieb:
Ause just informed me about another solution that might remove the
need to have the test run on every CWS i.e. we wouldn't need to have
the tests mandatory. His idea is to run the tests on the Master
Workspace prior to announcing the CWS as ready for CWS
Hi Mathias,
Mathias Bauer schrieb:
...
I know that each and every test I can make is able to find bugs and also
regressions. This is a correct but nevertheless trivial statement that
of course noone would deny. But for the same reason why QA nowadays does
not execute each and every test we
Hi Hennes,
Hennes Rohling schrieb:
...
But don't make everything mandatory. If I change a string in the setup
or change platform dependend code for systemintegration I don't want to
do a mandatory test that tests whether all dialogs in the Calc still work.
- Hennes
The problem with not
] Software Test Automation, Mark Fewster Dorrothy Graham,
Addison Wesley
[2] Slide 10
http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp
Jörg Jahnke wrote:
Hi,
in the past weeks I had some discussions with developers and members
from the QA
Hi Martin,
Martin Hollmichel schrieb:
Jörg Jahnke schrieb:
Hi,
one of the questions is whether it would be acceptable for everyone to
run a small regression test-suite prior to the QA-approval of a CWS.
These tests would probably run several hours, depending on the
hardware being used
Hi,
Oliver Specht - Sun Germany -Hamburg schrieb:
...
Hi,
before we all start dreaming:
Do you have such tests? Those that are able to find more regressions
than they overlook? Those that run only several hours not weeks like the
current ones?
A limited set of tests exists which could be
Hi Martin,
Martin Hollmichel schrieb:
...
I still think that making a test mandatory is not the first step in the
process. I would like to name these requirements with this priorities:
1. Test should be repoducible and generate easy to read and unambigious
logs with clear error codes.
Hi,
Mathias Bauer schrieb:
Exactly, and I would prefer to have regression tests based on the API or
complex test framework and not based on the GUI testtool. We shouldn't
raise even more barriers to contribution.
Ciao,
Mathias
I agree that we shouldn't raise additional barriers that keep
Hi Eike,
Eike Rathke schrieb:
The plan is to have an _easy_ way of running the tests. Whether a button
in the EIS application will be the best way I cannot say, but it seems
to be a good example.
So far the performance tests can't be run for CWSs that were not created
on Sun Hamburg servers.
Hi,
the reason why the Wiki page speaks of mandatory tests I have mentioned
in a previous mail:
Jörg Jahnke schrieb:
The problem with such tests not being mandatory is that, sooner or
later, some tests would break. That again would lead to a state where
the user of the tests could
Hi,
Nils Fuhrmann schrieb:
...
Beside these three things were we like to initiate a change, there are
currently things in progress which we like support more actively to
bring down some restriction and hurdles we have.
For CWSs, we typically like to see at least two installation sets on
Hi,
to go a step further: Do we need such feature mails at all? Couldn't we
instead offer RSS feeds (per project?) which list the most recently
integrated CWSs and their feature descriptions?
I could imagine that a developer can edit the feature description at any
time he likes and, at the
Hi,
the P1 issue i67982, that was found on the milestone m179 of SRC680,
brought up the question whether there might be cases when it is useful
to re-open a milestone that has already been announced as ready for CWS
usage, in order to integrate a P1 bugfix. As this matter does not only
Hi,
Tom Verbeek schrieb:
IMHO if the use of this web tool causes pain, and is unusable by
others, Sun should shoulder the burden here; and ultimately [ AFAIR ]
good icons take ~3 hours each to draw ; [ in 2 sizes ], and as such it's
unlikely that inserting 4 or 5 per day in some web tool
30 matches
Mail list logo
