| Re: [jdt-dev] "clean up" again |
Stephan,Speaking as an adopter, EMF has 32 uses of org.eclipse.jdt.internal in the code base. As such, sensitivity to adopters is very much appreciated. I know API rights activists will cry out about API violations and argue their inviolate right to make arbitrary changes because, well, they are within their rights of course. It seems one can't reasonably argue against such things because rights are always right. But reality is subtle and complex, with shades or gray ruling the day.
I can well imagine there are good reason why Object Teams is incestuously intertwined with JDT, so from a hundred paces away, to critique its design based purely on superficial, ideological dogma, with no actual deep understanding of that design, leaves a bad smell. Let's not do that. Balance and respect and more important than rights and rules and there are few more deserving of respect than Stephan.
Regards, Ed On 30.05.2020 14:16, Stephan Herrmann wrote:
Vetos, for sure, should be used sparingly and carefully.Yet, as part of their responsibility, committers need a way to reject changes, which they assess as having negative impact on the project.When I wrote "For compiler tests, however, I would veto any such change" I said so in full confidence that the active committers will agree.Regarding Object Teams, once more: this is a side issue (other than the fact that without Object Teams I would never have started contributing to JDT), and few people on this list have sufficient insights into that project to seriously discuss its architecture. We could just drop this, but I still believe there is an aspect that goes far beyond Object Teams:JDT is used by *many* adopters. Putting aside all design rules and ideology, it's a fact of life that some of them use internals of JDT, have perhaps been doing so for a very long time. We are not going to re-write other projects' history. On the contrary, as a courtesy to our adopters (who are an important part of the eco system!) we should minimize changes that are likely to cause grief and pain downstream. By "minimize" I mean: be a bit more conservative than usual, perform only those changes that are "necessary" in one way or other. Just raise the bar for approval.BTW: we have several deleted methods brought back after adopters have explained their problems with a change in JDT. Some of this looks quite odd and violates a number of rules, but if it helps adopters it helps the eco system, which is more important :)best, Stephan On 30.05.20 10:41, Gayan Perera wrote:I think this was a good discussion. But i think we need to have mix of people when doing veto. Other wise things will never move forward if we are stuck with the same group who thinks in the same way.I know stephan will not agree with me. But i think object teams have great technical debt from what i read in this thread. A product should no depend on tests of another product. Moving tests from one junit 3 to junit4 should not impact heavily. Use test fixtures instead of depending raw test classes. Look at how IntelliJ platform has done it for plugin developers.Rather than simply depending on a test plugin and writing your tests on it. Its always good to have APIs which are not bounded to certain implementation details on test frameworks.By the way cleaning up whitespace issues and cleaning up code formatting in a single commit as a bulk task, I don’t understand the what the big issue that stephan tries to highlight.Finally if you depend on non API classes then be prepared to get breaking changes. It shouldn’t matter how big the product is that depend on non API classes.Br, GayanOn Fri, 29 May 2020 at 18:50, <stephan.herrmann@xxxxxxxxx <mailto:stephan.herrmann@xxxxxxxxx>> wrote:Thanks for answers here and others.I feel we can agree that the JUnit3 -> 4 conversion is different from othermass changes:* This change is done with close consideration of each individual case rather than mechanically applying some scheme over unseen amounts of code. * I see a tangible benefit (during development / for reporting etc.), withjust few comments:- In JDT I never saw anything nearly as bad as what Alex linked (fromteam.cvs)- Once a new contributor realizes that he has issues with a new test method not being picked up, this should be the kind of question that should get a helpful hint from others in very short time. For simple questions likethis feel free to ping even in short intervals.- This JUnit migration causes significant follow-up work in Object Teams, but I was happy to get helpful explanations from Carsten and thus Idid not complain about this.* Test code is just a tiny little bit less critical than main code. This concerns cleanliness of the git history as well as bugs introduced by mass changes (= only indirectly affecting users, while still affecting adopters).I think in JDT/UI this particular activity is still ongoing, and I don't object to its completion (I have no idea about the percentage completed?). Ihope other committers can agree, too?For compiler tests, however, I would veto any such change. I'm a bit less decided about other tests in JDT/Core or JDT/Debug, but I feel terminatingthis activity when JDT/UI is done is a fair compromise, OK?Regarding save actions, I second what Jonah said. Actually I think it was a bug to enable any save actions that are not in sync with the existing code.I hope with this we can tick off two items from the list as being not quiteas controversial as some may have felt. Stephan Am 2020-05-28 15:52, schrieb Pyves .:I've contributed a few patches to JDT Core and UI in the past couple of years, so I'm guessing I fit in the "new contributors" category and may beable to provide some insight.My first contribution was fixing bug 424214 and I faced two problemsrelated to this discussion:* I struggled to write new unit tests. At the time, I had never used JUnit 3 (which is understandable given that JUnit 4 was released early 2006). Iwas probably trying to write a test method with a different namingconvention and it wasn't being picked up by the framework - no longer sure at this point. And as JUnit 3 was not a thing I had used, I didn't evenrealise it was JUnit 3 (in my mind it was some bespoke Eclipse test utility running) and consequently I couldn't easily look up anydocumentation to solve my problems. In the end, I ended up putting the tests in an existing file and copy-pasted as much possible, not really understanding how things fitted together. For anyone who has started writing Java in the past decade or so, these mass migrations to JUnit 4, even though they touch a lot of files and introduce commit noise, are useful. * I struggled to get the contribution under 1000 lines to avoid the CQ.The files I changed had not been cleaned up nor touched in years,therefore some of the automatic save actions had introduced additional diffs, for example import ordering. With Till Brichy's help I then had to revert some of these automatic changes, just for the sake of getting under the 1000 line limit in time for the M3 deadline. Note that this was my very first usage of Gerrit, so reverting lines and pushing new patch sets was not as straightforward for me as it would be now. "Fighting" against save actions would not have been needed had the files been cleaned upprior to my contribution.Admittedly, these are only two small inconveniences which some of you may even consider as anecdotal, but hopefully they do illustrate cases wheremass cleanups can help newcomers. :) Best regards, Pierre-YvesLe jeu. 28 mai 2020 à 15:08, Aleksandar Kurtakov <akurtako@xxxxxxxxxx<mailto:akurtako@xxxxxxxxxx>> a écrit : On Thu, May 28, 2020 at 3:07 PM Stephan Herrmann<stephan.herrmann@xxxxxxxxx <mailto:stephan.herrmann@xxxxxxxxx>> wrote:On 28.05.20 13:20, Aleksandar Kurtakov wrote: > On Thu, May 28, 2020 at 1:55 PM S A <simeon.danailov.andreev@xxxxxxxxx <mailto:simeon.danailov.andreev@xxxxxxxxx> > <mailto:simeon.danailov.andreev@xxxxxxxxx <mailto:simeon.danailov.andreev@xxxxxxxxx>>> wrote: > [...]> I can't make a comment on attracting other contributors in JDT.> > > That I can comment :).Are you speaking from your own experience of working on JDT code(as a new contributor), or are these words you put into the mouths of others? I'd appreciate if they speak for themselves.I speak as the tech lead for Jeff and Roland and discussions on a weekly basis what/how/when/why to do so we can share the burden in JDT with others. Being the one that have pushed for people to work on JDT and the one that has followed up most of the late additions to theteam and specifically organizing the team work so JDT team andcommunity can grow - yes I do speak from my own experience and would dare to even say that have a broader view of the project not worsethan many committers. I haven't worked on JDT code itself a lot (releng fixes afterincomplete fixes in JDT and -Werror addition) but I would dare to say that non-trivial part of the work in the last few releases has beenrequested by/approved by/checked by/etc. by me personally incl. freeing time for people to work on JDT and further .I'm willing to learn from our new contributors. It's among thecommitters thatwe have to find a mode of operation that facilitates collaborationand avoidsstepping on each others' toes. It seems this mode has not yet beenfound.> P.S. Only whoever hasn't looked at unreadable JUnit3 testsuites results [...]I'm looking at such results [1] all the time and I see no problem.Do you care to be more specific? https://download.eclipse.org/eclipse/downloads/drops4/R-4.15-202003050155/testresults/html/org.eclipse.team.tests.cvs.core_ep415I-unit-win32-java8_win32.win32.x86_64_8.0.html- go even figure which test triggered the failing setup. You want see it in later builds cause these specific tests have been disabled and other such has been updated to JUnit4 - doing it regularly when mydaily look at test results spots such thing. Stephan [1] https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Gerrit/lastStableBuild/testReport/ _______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev -- Alexander Kurtakov Red Hat Eclipse Team _______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev _______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev_______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev _______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev_______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev