[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] "clean up" again
|
+1 of course.
Regards,
Manoj
-----jdt-dev-bounces@xxxxxxxxxxx wrote: -----
To: jdt-dev@xxxxxxxxxxx
From: Stephan Herrmann
Sent by: jdt-dev-bounces@xxxxxxxxxxx
Date: 06/01/2020 03:07PM
Subject: [EXTERNAL] Re: [jdt-dev] "clean up" again
+1 with one clarification (should be obvious):
as for every bug, also here it's the responsibility of the reporter to give
reason, why a proposed change is relevant.
Stephan
On 01.06.20 09:37, Sarika Sinha wrote:
>
> 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 <mailto:-----jdt-dev-bounces@xxxxxxxxxxx>
> wrote: -----
> To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx
> <mailto:jdt-dev@xxxxxxxxxxx>>
> From: "Manoj Palat"
> Sent by: jdt-dev-bounces@xxxxxxxxxxx <mailto: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 <mailto:-----jdt-dev-bounces@xxxxxxxxxxx>
> wrote: -----
> To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx
> <mailto:jdt-dev@xxxxxxxxxxx>>
> From: "Jayaprakash Arthanareeswaran"
> Sent by: jdt-dev-bounces@xxxxxxxxxxx <mailto: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 <mailto:-----jdt-dev-bounces@xxxxxxxxxxx>
> wrote: -----
>
> >To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx
> <mailto:jdt-dev@xxxxxxxxxxx>>
> >From: Gayan Perera
> >Sent by: jdt-dev-bounces@xxxxxxxxxxx <mailto: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
> <mailto: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>
> > >> <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>
> > >>> <mailto:akurtako@xxxxxxxxxx>> a écrit :
> > >>>
> > >>>
> > >>> On Thu, May 28, 2020 at 3:07 PM Stephan Herrmann
> > >>> <stephan.herrmann@xxxxxxxxx <mailto: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
> > >>> <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> <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> <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> <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> <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 <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 <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
