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 appreciate the more somewhat more balanced tone today and I apologize for my decidedly snippy commentary yesterday.

On 03.06.2020 09:06, Mickael Istria wrote:
Hi Jay,

On Wed, Jun 3, 2020 at 8:31 AM Jayaprakash Arthanareeswaran <jarthana@xxxxxxxxxx> wrote:
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"
Blame annotations are very useful, in my opinion, and it's sad and decidedly harmful when they become useless.  As a contributor to many projects, it's frustrating to me when the history of semantically important changes are lost in a sea of reformatting and other style changes.  It makes it difficult to understand why the code is the way it is without a lot of additional detective work.  That too is a barrier to contribution.
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?
I don't believe these folks feel only they are good enough.  Speaking from my own perspective, I'm a bit of a control freak, and I like to understand every last line of my code.  It's not that I think I'm better than other people, it's just that in the end I am (or at leave feel that I am) personally responsible for every last line of code.  I understand that this is a bit pathological.
And even further, which one would your project manager choose as being the most strategic in mid/long-term?
Also speaking from experience, managers like to move people from project to project on a regular basis because it's easier to manage "resource" in this way.  So I'd not put a lot of weight in what my manager wants; that's why I avoid having one in the first place.
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 can well imagine the answer. :-)
Relying on a few non-replaceable people is a risk for the project they support, it's management 101.
Yes, exactly.  Management 101.  Unfortunately most often the manager is clueless about the nature of the "resource" they manage and about the intricate details of technology itself.  It's all just "resource" to manage and best make all "resource" interchangeable...
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.
Yes, certainly we all die at some point, so there does need to be new "resource" eventually.
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.
Well, that's kind of the point.  Who reaps the profit?  The "resource" being managed perhaps pays a large cost for the profit of others.
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).
Yes, this is a fact.
This risk is strategically much bigger than the risk of something broken in the code from time to time.
I believe it comes down to who actually pays with their time and/or money?  If to a large extent that is the burden born by those already working their assets off, then you can see why there is resistance no matter how strong and correct your arguments are.  And your arguments are both strong and correct.


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

Back to the top