Everyone, I find it extremely disappointing that we have this discussion again and that people are looking at things so selfishly!!! Do we as a community care about our own time only? That would mean there is no community to start with! Let's put it that way: * I have probably fixed bugs caused by any of you (and never made noise about it until now !!! - as it should be in a true community) * You have fixed bugs caused by me * You have helped me identify and fix issues * I have identified and explained issues to you So what is worth more to do users of Eclipse - your time fixing stuff I broke or my time fixing stuff you broke? Let me tell it straight - both are priceless because without the collaboration I would keep banging my head over e.g. jdt.core or equinox issue and you'll do the same over some swt or maven issue. If we fail to understand that we fail at understanding the basic principles of open source and its mechanics. Let me remind you that everything is a giant cycle so these so called useless cleanups are actually helpful to a number of people - e.g. the whole Red Hat team. Know it or not our environment is a build from source one so if these changes are not done by other members of the community we would have to do it ourself as we really pay attention to our build logs to identify and be able to use different version of dependencies and etc. As you would have to guess if we spend our time on this that would automatically mean less time on JDT, Releng, Platform, Tycho, WildWeb, ShellWax .... And we can work on all this only because there are the people doing the core work AND there are the people doing the cleanup part!!! The sooner people start to look at the bigger picture and out of their silo, the sooner we will be able to gain more out of the strong sides of every member of the community!
On Tue, Jan 21, 2020 at 7:44 PM Lars Vogel <[email protected]> wrote: > Andrey, > > This comment sound a bit aggressive and without a clear benefit. Please > avoid such comments. If my comment to Sarika sounded the same way, I'm > sorry that was not the intention. > > I think we all agree that change can cause issues and that no change do > not cause direct issues. But changes also have benefits. For example look > at the performance tests for 4.15 in which we improved in almost all areas. > > The normal process is that if a change creates issues we fix or revert it. > Yesterday was bad in the sense that lots of stuff was merged at the same > day and that we hand several build issues before that. > > The PMC discussed today that we will try to rerun the tests, if that does > not work restart the test machine and if that does not fix the tests try to > revert the changes. > > Best regards, Lars > > > Andrey Loskutov <[email protected]> schrieb am Di., 21. Jan. 2020, 18:30: > >> 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 < >> [email protected]>: >> >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 <[email protected]> >> >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 <[email protected]> >> >> Sent by: [email protected] >> >> To: "Eclipse platform general developers list." >> ><[email protected]> >> >> 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 <[email protected]> >> >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 >> >> [email protected] >> >> 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 >> >> [email protected] >> >> 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 >> >> [email protected] >> >> 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: [email protected], Web: >> >http://www.vogella.com >> >_______________________________________________ >> >platform-dev mailing list >> >[email protected] >> >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 >> Спасение утопающих - дело рук самих утопающих >> _______________________________________________ >> platform-dev mailing list >> [email protected] >> 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
