Hi Mickael
> mitigate this risk, there is no other way than trying to get more people involved in the project to learn from the experts, progressively taking care of some of their tasks
I believe the goal above can't be achieved by applying automatic cleanups that do not require any knowledge in JDT and do not fix any of tasks we have on table. I'm not aware about new JDT or Platform UI contributors who would made a conversion from "mass cleanups" to full committer just by doing "mass cleanups", and even if that would happen - what kind of work would this committer be able to do, having only gained "JDT experience" by clicking Source->Cleanup... menus?
Let put JUnit conversion (which is *not* an "automated mass clean up") by side - all other mass cleanups we are talking here about (lambdas/forech/stringbuilder etc conversions) do not fix any known/potential issue, nor increase the JDT core knowledge by people applying them. "Touching" 100+ files with a script is not gaining JDT knowledge, but introduces even more burden on the JDT team to review that and after merge to fix regressions that wouldn't be there without "automatic" cleanups.
Changing one single file manually to fix known bug, plus adding a test for compiler *do* increase JDT knowledge.
> An OSS project community that is not willing to welcome and train new contributors is IMO putting an extremely high risk on the project
This is simply not true. I personally monitor & reply on bugs and assist people that provide *real* fixes to JDT, and I know Stephan does lot of bug processing for incoming compiler issues. We *welcome* *real* contributions, if they are not just "automatic mass cleanups".
Speaking from my personal experience with JDT (I do not consider myself as a "core" JDT developer) - I was welcomed by Stephan and he assisted me in most of my JDT patches, so that I know now *a bit* more how JDT works, and I can provide sometimes JDT patches that even work :-). However, even after many real fixes in JDT I do not consider myself capable to do the work Stephan & Co do, just because the knowledge needed there is very special. You must be willing to study JVM specs & compiler / language architecture, and this is not something one can get by "mass cleanups".
> Which one do you think Red Hat, which is investing in Eclipse stack and consuming it downstream, should encourage to make it's JDT-based offering last the longest?
I fully agree with the goal that we should try to attract more people to contibute to JDT, but the way proposed here is wrong.
If RH/whoever wants to invest in JDT, the right way is to encourage people to work on *real* JDT bugs, so they can start to learn JDT, instead of encouraging people to apply automatic cleanups.
Kind regards,
Andrey Loskutov
Спасение утопающих - дело рук самих утопающих
https://www.eclipse.org/user/aloskutov
Gesendet: Mittwoch, 03. Juni 2020 um 09:06 Uhr
Von: "Mickael Istria" <mistria@xxxxxxxxxx>
An: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>
Betreff: Re: [jdt-dev] "clean up" again
Hi Jay,
If I had to chose between "a couple of contributions that don't bring much to the
table but have the potential to break something and make my life difficult to making
the blame annotations useless" and "keeping the existing high-value committers in high spirit
by not putting them through this kind of breakages that could cost them their weekend,
discussions like these in the name of broader mind", then I will go with the latter
every single time.
Let's try another choice (which is a corollary): if you have to choose between "JDT becomes a more diverse project with more contributors, but at the cost of something broken from time to time, and useless blame annotations" and "Only Jay and Stephan and a few other blessed people work on JDT forever because apparently we assume all other committers are not good enough for this task", which one would you chose? And even further, which one would your project manager choose as being the most strategic in mid/long-term? Which one do you think Red Hat, which is investing in Eclipse stack and consuming it downstream, should encourage to make it's JDT-based offering last the longest?
Relying on a few non-replaceable people is a risk for the project they support, it's management 101. So to mitigate this risk, there is no other way than trying to get more people involved in the project to learn from the experts, progressively taking care of some of their tasks. Of course, this is not perfect at 1st try, it requires training, and this is sometimes extra work for the experts to deal with this "training". But in the end, it's profitable for everyone.
An OSS project community that is not willing to welcome and train new contributors is IMO putting an extremely high risk on the project of dying as soon as a few individuals reduce their investment (for whichever reason). This risk is strategically much bigger than the risk of something broken in the code from time to time.
Cheers
_______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
