A way to handle this is to designate a specific individual per component – possibly on a rotating basis, say on a weekly tenure – to track build/test failures, triaging incoming issues and answer
general queries that come up.
Srikanth
From: eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx>
On Behalf Of Manoj Nalledathu Palat via eclipse-dev
Sent: 14 October 2024 14:44
To: Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>; Eclipse platform general developers list. <platform-dev@xxxxxxxxxxx>; General development mailing list of the Eclipse project. <eclipse-dev@xxxxxxxxxxx>; Equinox development mailing list
<equinox-dev@xxxxxxxxxxx>; Eclipse PDE general developers list. <pde-dev@xxxxxxxxxxx>
Cc: Manoj Nalledathu Palat <manoj.palat@xxxxxxxxxx>
Subject: Re: [eclipse-dev] [jdt-dev] Eclipse SDK tests stability
CAUTION: This email was sent
from outside of Advantest.
Well said Alex! Am also guilty of being irregular here. Was wondering whether we can track this by a master issue in platform releng which can have child issues to each of the sub-modules?
I saw Michael Istria’s message -
https://www.eclipse.org/lists/jdt-dev/msg02442.html about - https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/2451
– am yet to receive it in the mail though – so not able to reply to that. So was wondering whether we can have a sub-issue per-release for each of the participants – eg one issue for jdt.core, jdt.ui, etc.. where we will update the I-build we checked the test
results – only one issue per component per release. This way we can track in a systematic way as well.
Suggestions/opinions welcome
Regards,
Manoj
Hey everyone, I can no longer hold this email! There is obvious instability in the test results of our night build (e. g.
see https: //download. eclipse. org/eclipse/downloads/drops4/I20241013-1800/).
Unfortunately this is not an isolated case
I can no longer hold this email!
Unfortunately this is not an isolated case lately (look at old builds in
https://download.eclipse.org/eclipse/downloads/index.html Integration builds and you will notice that most of the old builds have at least double digit number of test failures and many
ever 3!). The worst part seems to be that committers don't seem to check and this results regularly.
Try to look at the last night's build result and investigate things thoroughly as your morning routine and if you have submitted any change on the previous day - that should be MANDATORY!
Current status of a very small number of people keeping a look at the results, investigating where the failure comes from and why is not sustainable in any way as most of the time this is far more time than actually fixing the problem after
analysis.
I hope that all of you understand correctly that if this doesn't happen (immediately) the quality of our next releases will be under risk.
P.S. Improving tests (and infrastructure) so more of the issues are catched by verification builds is of course even better so you're more than welcome to land a hand there too!
