-1 from me also. If we use the
repository as a place of discussion we'll quickly descend into
chaos.
P.S. I've had colleagues many years past that used code comments
as a place of discussion because they failed to communicate
effectively. I still come across these comments sometimes as a
sad reminder. We've always maintained a civil tone in CDT even
over major disagreements. So I sincerely hope we won't turn our
git log into a similar sad reminder.
On 08/24/2012 10:28 AM, Sergey Prigogin wrote:
I've reverted the commit http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=1bd247ce3d8825b76623166a89b111884ae1b195
since nobody expressed interested in it except John and since John
can continue to use it in his local branch.
BTW, org.eclipse.cdt.alltests.AllTests.java doesn't have a
copyright header.
-sergey
On Tue, Aug 21, 2012 at 12:05 PM,
Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx>
wrote:
I propose
to revert the commit http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=1bd247ce3d8825b76623166a89b111884ae1b195.
John, you can keep the commit on a local branch if you
prefer.
-sergey
On Tue, Aug 21, 2012 at 11:55
AM, Cortell John-RAT042 <RAT042@xxxxxxxxxxxxx>
wrote:
Andrew,
If the filters I added did not cover
failures seen by someone else, and that
person also wants to have a reliable test
suite, then he should add additional
filters. If I see additional unreliable
tests in future runs, I will add filters for
them.
I wish creating a bugzilla report would
result in these intermittent failures
being fixed. But I'm not going to hold my
breath and I'm not going to waste time
creating bugzilla reports for tests that
someone has written but has not ensured
they run successfully and consistently on
Windows. As you already know, there are
intermittent failures even on Linux. I've
spent a considerable amount of time
debugging and fixing ones I could tackle.
But I have to move on.
What I want is to be able to run a CDT
test suite locally and have zero failures,
based on what's in git. Sadly, with these
filters, I've reduced the overall test
suite from about 12K tests to 3K[*]. I've
had to filter entire chunks because
failures happen not only intermittently
but in random locations within the
particular chunk. Hopefully someone who
has the time and motivation to run and
troubleshoot these tests on Windows will
try to address this situation.
I said it before and I'll say it again:
a test suite that produces dozens of
failures is all but useless for regression
detection. I want a test suite that passes
100%. What I've done is rigged the tests
so that I and others can get that subset
with the flip of a switch.
John
[*] Again, these filters must be
manually activated. By default, all tests
still run.
Hi John,
This approach does not look
particularly scalable. Is it
intended that every commiter
will add to the CDT code
filters for individual tests
that fail in his/her
environment?
//
Consistently fails, and,
yes, I do have Cygwin in my
PATH
if
(System.getProperty("cdt.skip.known.test.failures")
!= null) { //$NON-NLS-1$
return;
}
Why don't create a bug in
bugzilla instead to fix the
problem for good?
Thanks,
Andrew
On
Fri, Aug 17, 2012 at 12:49
PM, Cortell John-RAT042
<RAT042@xxxxxxxxxxxxx>
wrote:
I
was able to
resolve roughly a
dozen intermittent
failures caused by
a bug in
org.eclipse.cdt.ui.tests.BaseUITestCase.checkTreeNode(IViewPart,
int, String)
The
implementation
searched the
entire workbench
for the SWT Tree
instead of just
the given view.
This would
intermittently
(but frequently
enough) return,
e.g., the Outline
view’s tree
because it has a
root element with
the same label as
that in the Call
hierarchy view. It
was just a matter
of the order in
which the controls
in the workbench
were found, which
is undefined and
inconsistent.
So,
here we have an
example of a test
being unreliable,
unrelated to OS or
environment. The
test had a bug and
you and Hudson
were simply
getting lucky.
I’ve
pushed the fix to
master.
John
> Since we
don't have Hudson
on Windows
There is a
Windows Hudson
slave, isn't
there? A job
could be set up
to run either
the full CDT
build or just
the tests on it.
Andrew
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|