> And I guess there are more, we just don't see them because our test coverage is not the best.
> I don't know why should we continue this practice of blind "mass changes" for no good reason, that caused so many regressions so far.
> If this sounds as too much work, I would propose to re-think the "benefit" of mass changes.
> If we continue in the same way as today, at some point in time the code is "fully optimized" but Eclipse is not usable anymore.
I agree with Andrey that may be we should rethink on the strategy of mass changes as it takes a lot of productive time of a few committers in going through the changes and analysing the regressions unless other committers come forward to share this responsibility.
In the past, most of the regressions caused by mass changes are OS independent for example:
With power comes responsibility and the contributor/committer and the reviewers must take the responsibility to test the impacted areas in UI as we don't have enough test coverage. Before merging any contributor/committer and the reviewers can seek help from the community to test on other platforms if they don't have access to them.
Thanks & Regards,
Sarika
----- Original message -----
From: Aleksandar Kurtakov <akurtako@xxxxxxxxxx>
Sent by: platform-dev-bounces@xxxxxxxxxxx
To: "Eclipse platform general developers list." <platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [platform-dev] Mass changes again
Date: Tue, Jan 21, 2020 2:42 PM
Hi,
we had numerous regressions in two last builds, I've opened
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559352
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559353
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559355
And I guess there are more, we just don't see them because our test coverage is not the best.
I don't know why should we continue this practice of blind "mass changes" for no good reason, that caused so many regressions so far.
My best example of such regression, on which I've spent a full work week of my time, was https://bugs.eclipse.org/bugs/show_bug.cgi?id=551147.
I'm tired to spend my time to do house keeping for others, and I don't see anyone else doing this work. I don't think this is fair.
I would propose that committers that merge "mass changes" *must* do the work I do:
1) Check SDK build results after integration of mass changes and identify new failures
2) Report bugs for new failures
3) Identify offending commits and notify authors
If this sounds as too much work, I would propose to re-think the "benefit" of mass changes.
If we continue in the same way as today, at some point in time the code is "fully optimized" but Eclipse is not usable anymore.
This actually brings one very significant problem - Mac and Windows builds are unstable for probably a year now (or even more!). This is long enough period for contributors to gain the habbit of just ignoring test results on Mac and Windows. I can't blame anyone for that (thanks Andrey for still checking them!).
IMHO is current failing tests on Mac and Windows tests can't/won't be fixed ASAP - these should be run only on Linux so seeing test failure finally means there is something to be looked at. As it should have always been.
Lakshmi, Niraj, as you're respective SWT port maintainers and the long failing tests are UI related: What is your opinion on this?
Kind regards,
Andrey Loskutov
Спасение утопающих - дело рук самих утопающих
https://www.eclipse.org/user/aloskutov
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
--
Alexander Kurtakov
Red Hat Eclipse Team