Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] "clean up" again


I do not like the disrespectful tone into which this discussion has digressed.  This is a never ending thread.  I certainly do not appreciate nor accept the concept that one person sees the "bigger picture" with the implication that all the others see only a narrow picture that is somehow of less worth.  People have previously said things that I see as insulting. It's clear that others have perceived the comments as insulting.  But there was no need to apologize was there?  No, let's just keep hammering down the path of perfect progress, knowing full well that there are sensitivities down this path.  The steamroller is not easily brought to a halt, not when rights drive it right.  Who actually cares about people or how they feel?  Apparently that's in no way relevant.

I imagine that it must be nice to have interns.  Perhaps if Stephan had a few interns to direct he would be able to accommodate the churn that's created by clean-up, refactoring, and moving to JUnit X++, not to mention the steady march of new Java versions.  But he doesn't.  He's brilliant, he's a really nice person, and he should be treated with respect.  We should not presume that he is a bottomless pit of resource to accommodate our every wish and demand, however strong the technical arguments are to back those demands.  Please keep in mind that without human beings, technology is irrelevant, and that there is a big difference between what's right, what's ideal, what's practical, and what's possible for a single person to accomplish in their waking hours.

To be really politically incorrect, the millions of freeloaders, including and especially the bloated billion Euro/Dollar corporations, all of whom benefit from Stephan's brilliance, could in principle squeeze open their sticky wallets to contribute something more than idealistic dogma.


On 02.06.2020 22:34, Stephan Herrmann wrote:

the way I read your mail, you seem to be saying that I'm narrow minded, or irresponsible, or incompetent, or having a bad attitude, or all of the above.

I feel insulted.

If you want to continue communicating with me, I need an apology.


On 02.06.20 16:56, Aleksandar Kurtakov wrote:

On Fri, May 29, 2020 at 7:50 PM <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 other
    mass 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.), with
    just few comments:
        - In JDT I never saw anything nearly as bad as what Alex linked (from
        - 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 like
    this 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 I
    did 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?). I
    hope 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 terminating
    this activity when JDT/UI is done is a fair compromise, OK?

I tried to not reply here but just think a second about the broader picture - our releng includes JUnit 3/4 and soon 5 tests . There is code launching tests in different way, there is other code aggregating test results and etc. - this all comes at a price and this price is paid by people working so some bits end up released. So SWT tests are moving to JUnit 5 (I do care my interns to be able to work on it right from school). And I *veto* the work for supporting 3 different test technologies/results in platform.releng.  Or I decide that next Tycho won't support JUnit3 tests. Where would that put the project? I really suggest people to reconsider their attitude as nothing lives in vacuum and we are all interdependent. Thus saying "I would veto any such change" is a recipe for disaster.

    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 quite
    as controversial as some may have felt.

    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 be
    able to provide some insight.
    My first contribution was fixing bug 424214 and I faced two problems
    related 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). I
    was probably trying to write a test method with a different naming
    convention 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 even
    realise it was JUnit 3 (in my mind it was some bespoke Eclipse test
    utility running) and consequently I couldn't easily look up any
    documentation 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 up
    prior 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 where
    mass cleanups can help newcomers. :)
    Best regards,

    Le 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
            > <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 the
        team and specifically organizing the team work so JDT team and
        community 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 worse
        than many committers.
        I haven't worked on JDT code itself a lot (releng fixes after
        incomplete 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 been
        requested 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 the
            committers that
            we have to find a mode of operation that facilitates collaboration
            and avoids
            stepping on each others' toes. It seems this mode has not yet been

             > P.S. Only whoever hasn't looked at unreadable JUnit3 test
            suites results [...]

            I'm looking at such results [1] all the time and I see no problem.
            Do you care
            to be more specific?
        - 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 my
        daily look at test results spots such thing.


            jdt-dev mailing list
            jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
            To unsubscribe from this list, visit

        --         Alexander Kurtakov
        Red Hat Eclipse Team
        jdt-dev mailing list
        jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
        To unsubscribe from this list, visit

    jdt-dev mailing list
    jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
    To unsubscribe from this list, visit

    jdt-dev mailing list
    jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
    To unsubscribe from this list, visit

Alexander Kurtakov
Red Hat Eclipse Team

jdt-dev mailing list
To unsubscribe from this list, visit

jdt-dev mailing list
To unsubscribe from this list, visit

Back to the top