Hi Aleks,
Create
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/2454 as the umbrella issue for tracking on an experimental basis. Have created sub-components for jdt here.
Regards,
Manoj
From:
eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> on behalf of Aleksandar Kurtakov via eclipse-dev <eclipse-dev@xxxxxxxxxxx>
Date: Monday, 14 October 2024 at 3:05 PM
To: General development mailing list of the Eclipse project. <eclipse-dev@xxxxxxxxxxx>
Cc: Aleksandar Kurtakov <akurtako@xxxxxxxxxx>, Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>, Eclipse platform general developers list. <platform-dev@xxxxxxxxxxx>, Eclipse PDE general developers list. <pde-dev@xxxxxxxxxxx>, Equinox development
mailing list <equinox-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [eclipse-dev] [jdt-dev] Eclipse SDK tests stability
On Mon, Oct 14, 2024 at 12: 18
PM Sankaran, Srikanth via eclipse-dev <eclipse-dev@ eclipse. org>
wrote: 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
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.
Everything is possible given there are people working towards a given goal. I don't think there is a way to mandate such a thing to committers per EDP (https://www.eclipse.org/projects/dev_process/)
so it would be very nice if each subproject organizes itself to do such triaging.
I'll express my concern over the too big single SDK which is just too fragile as e.g. JDT has to be constantly in sync with changes(issues) in Platform and or PDE and vice versa. Sub projects having their own builds and contributing to
simrel on their own will provide a fixed integration points and overall eliminate looking into nightly issues that get fixed in a few days but during this time affecting all subprojects in the current setup. Of course that will come at the extra price of a
certain group of issues being found far later in the process. I'm not 100% convinced this would be a totally better approach but given the current status if nothing changes we will just all sink so my eyes are set towards such a change right now.
Srikanth
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!
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev
--
|
