Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-dev] Mass changes again

Lars,

you don't really want me to provide you list of all regressions I've seen caused by mass changes, or do you?

Am 21. Januar 2020 18:09:21 MEZ schrieb Lars Vogel <lars.vogel@xxxxxxxxxxx>:
>Sarika,
>
>only one of your examples is a "mass change". Both
>https://git.eclipse.org/r/#/c/154926/ and
>https://git.eclipse.org/r/#/c/153288/ changed only one file.
>
>Best regards, Lars
>
>On Tue, Jan 21, 2020 at 4:45 PM Sarika Sinha <sarika.sinha@xxxxxxxxxx>
>wrote:
>>
>> > 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:
>>
>> Gerrit  https://git.eclipse.org/r/#/c/154926/ caused 4.15 M1 respin
>with Bug 558991.
>> Gerrit https://git.eclipse.org/r/#/c/144099/ causing Bug 549222
>> Commit
>https://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=176312d9c10572510576b11df4e711a4d118025e
>causing Bug 553276
>>
>>
>> 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
>>
>>
>>
>> On Tue, Jan 21, 2020 at 10:46 AM Andrey Loskutov <loskutov@xxxxxx>
>wrote:
>>
>> 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
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>
>
>
>-- 
>Eclipse Platform project co-lead
>CEO vogella GmbH
>
>Haindaalwisch 17a, 22395 Hamburg
>Amtsgericht Hamburg: HRB 127058
>Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
>USt-IdNr.: DE284122352
>Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web:
>http://www.vogella.com
>_______________________________________________
>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

--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих


Back to the top