Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] "clean up" again
A few individual items from this conversation that I am jumping in on:

> * I struggled to get the contribution under 1000 lines to avoid the CQ. 

This concerns me - there really shouldn't be any (significant) effort in getting the contribution under 1000 lines to avoid the CQ. CQs are not punishments and the 1000 lines is supposed to be measuring the the difference between a significant and non-significant contribution. I am going to bring this topic to the Eclipse architecture council because I keep seeing this type of behaviour over and over again and each time it frustrates me that new contributors are ever told that their contribution is "too big".

> The files I changed had not been cleaned up nor touched in years, therefore some of the automatic save actions had introduced additional diffs

In this case I would strongly encourage committers to help the new contributor and apply the save actions to the modified files as a separate gerrit. With the committer doing it, it removes all doubt CQ wise and means that review of the "real" change is not affected by refactoring. CDT did code formatting/whitespace/cleanups to the entire code base in one go and I am glad we just took the hit once so that day to day I am not having to deal with what I used to have to deal with. I wrote some scripts to be able to cherry-pick changes across branches with different formatting styles and clean-ups applied*. This was a particular issue as there are lots of forks of CDT.

> 2. The top commits are indentation / style change / a revert thereof. This breaks the history annotations and often I have to resort to gitk to quickly find the origin of a line.

FWIW The Show Revision Information UI in Eclipse is excellent and by far my favourite part of egit (I use command line git for much of my other interactions).

HTH
Jonah

* Perhaps there should be a bug for this - but there is no way I know of to run JDT cleanup actions from the command line, so the tricky part of the script was to use EASE to automate the JDT cleanups from an open GUI.

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Thu, 28 May 2020 at 09:53, Pyves . <pyvesdev@xxxxxxxxx> wrote:
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> a écrit :


On Thu, May 28, 2020 at 3:07 PM Stephan Herrmann <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>> 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-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 my daily 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
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
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

Back to the top