As a learning from this episode, let us vote for creation of bug as mandatory for all components in JDT - Core/Debug/UI/Docs/APT/Text.
+1 (Implicit from me)
Note: It hardly takes 20 seconds to create a bug and we all know the advantages.
Thanks & Regards,
Sarika
-----jdt-dev-bounces@xxxxxxxxxxx wrote: -----
To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>
From: "Manoj Palat"
Sent by: jdt-dev-bounces@xxxxxxxxxxx
Date: 06/01/2020 11:53AM
Subject: [EXTERNAL] Re: [jdt-dev] "clean up" again
---Snip from Stephan Herrmannn---
>From here I think that it's clear that every change in JDT should start with a
>bugzilla entry, and this entry should start with a problem description. If we
>don't agree on smth being a problem, then obviously there is no reason for a
>change. Without a reason there will be no code change in the master branch.
Augmenting to what Stephan mentioned: From a previous discussion alongwith Lars, Stephan, and others a few months back we had
agreed that for every cleanup in JDT Core there will be a bug, and based on the
discussion, the bug will have a [cleanup] tag, only then we will proceed and also that these
cleanups will be taken up only in M1. There will be a limit on the number of mass cleanups that goes in at a time as well
and that the fixing of these cleanup bugs will not be counted for committer election. And these guidelines have been adhered to largely in
JDT Core, thanks to all! I agree completely with Stephan on this and would think the rest of JDT (other
than Core) will also be benefitted if we follow a bug-for-a-cleanup policy.
>This explicitly opens up for the case where some code section is beyond repair
>by normal means: If a certain code area is incomprehensible or does not allow a
>decent fix for a known bug, then this structure can be a problem in itself,
>worth cleaning up.
We do have multiple examples here, for example, Mateusz Matela - He redesigned the formatter completely,
and stayed on to fix and improve the same - and even now, after several years, he actively fixes and
enhances the redesigned code - This was a "real code cleanup" or actually code transformation which made
a significant improvement together with his continued and focused commitment. Till, another name Jay
mentioned focused on specific parts of JDT and the cleanups if any proposed by these, would take into account
the programmatic improvements as well as the effects/clients of their "owned" modules, and would turn out to
be more "informed" decisions. That said, this isn't a blocker for mass cleanup, will continue to attend to mass cleanups
as mentioned in the first paragraph.
Thanks,
Manoj.
-----jdt-dev-bounces@xxxxxxxxxxx wrote: -----
To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>
From: "Jayaprakash Arthanareeswaran"
Sent by: jdt-dev-bounces@xxxxxxxxxxx
Date: 06/01/2020 09:26AM
Subject: [EXTERNAL] Re: [jdt-dev] "clean up" again
>I do agree with internal API usages, even my self I have used
>internal APIs in a few of my plugins in Eclipse JDT. I'm not saying
>we should not do that, but we should have a process of promoting such
>most wanted internal APIs into external APIs to be more maintainable.
>And internal API users must have some CI jobs to make sure the
>upstream is breaking things for you. So we can raise those as soon as
>possible rather than waiting until an RC release. And for me, this is
>what Continuous Integration is about.
The fact that JDT is still compiled with JavaSE 8 and that it still supports
Java compliances all the way down to 1.1 is an example of what a widely
used project like JDT has to deal with. We, just like everyone, would like to
shed few lines of code, drop support for older versions etc. But then, that is not
what reality is and it will be nice if people take away this point from those
dealing with it for years. Remember, these are the same people that
have to rush to fix when things get broken by a mass change.
>Maybe you in JDT have a different approach in seeing quality,
>module design, and CI than what I used to, given the fact that you
>have lot of projects depending on you.
Yes, JDT, especially jdt.core project has very different priorities for reasons
that have been mentioned a few times already in this thread.
I also wanted to highlight that we have had new committers coming in like
Till, Mateusz etc. and I don't recall them requiring a clean-up work to get
them fired. Yes, not everyone uses same methods, but at the end of the day,
when cons outweigh pros, then we need to rethink our priorities.
Regards,
Jay
-----jdt-dev-bounces@xxxxxxxxxxx wrote: -----
>To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>
>From: Gayan Perera
>Sent by: jdt-dev-bounces@xxxxxxxxxxx
>Date: 05/31/2020 02:19PM
>Subject: [EXTERNAL] Re: [jdt-dev] "clean up" again
>
>I see that my last post had few raise eyebrows.
>
>I do agree with internal API usages, even my self I have used
>internal APIs in a few of my plugins in Eclipse JDT. I'm not saying
>we should not do that, but we should have a process of promoting such
>most wanted internal APIs into external APIs to be more maintainable.
>And internal API users must have some CI jobs to make sure the
>upstream is breaking things for you. So we can raise those as soon as
>possible rather than waiting until an RC release. And for me, this is
>what Continuous Integration is about.
>
>Maybe you in JDT have a different approach in seeing quality,
>module design, and CI than what I used to, given the fact that you
>have lot of projects depending on you.
>
>Maybe no point of raising the same thing again and again,
>just wasting all of our time.y
>
>Br,
>Gayan.
>On Sun, May 31, 2020 at 6:27 AM Ed Merks <ed.merks@xxxxxxxxx> wrote:
>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,
> >> Gayan
> >>
> >> On 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 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
> >> team.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 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?
> >>
> >>
> >> 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.
> >> 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 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,
> >>> Pierre-Yves
> >>>
> >>> 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
> >>> <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 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
> >>> found.
> >>>
> >>> > 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?
> >>>
> >>>
>https://download.eclipse.org/eclipse/downloads/drops4/R-4.15-20200305
>0155/testresults/html/org.eclipse.team.tests.cvs.core_ep415I-unit-win
>32-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 my
> >>> daily look at test results spots such thing.
> >>>
> >>>
> >>> Stephan
> >>>
> >>> [1]
> >>>
>https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Gerrit/lastStableBuil
>d/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@xxxxxxxxxxx
> >> To unsubscribe from this list, visit
> >> https://www.eclipse.org/mailman/listinfo/jdt-dev
> >>
> >
> > _______________________________________________
> > jdt-dev mailing list
> > jdt-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/jdt-dev
> _______________________________________________
> jdt-dev mailing list
> jdt-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
>https://www.eclipse.org/mailman/listinfo/jdt-dev
> _______________________________________________
>jdt-dev mailing list
>jdt-dev@xxxxxxxxxxx
>To unsubscribe from this list, visit
>https://www.eclipse.org/mailman/listinfo/jdt-dev
>
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
