Hi all,
Please see discussion on https://git.eclipse.org/r/#/c/132436/ and also on https://git.eclipse.org/r/#/c/131015/.
I've rejected patch https://git.eclipse.org/r/#/c/132436/ with -2 and voted -1 on https://git.eclipse.org/r/#/c/131015/.
At the end I was asked to bring the issue "how/what the project should value more" to PMC.
Thank you Andrey for bringing it here! It is the right way to do it and the project comes with a clear statement so we don't end up in cases where one committer encourages a person to do such changes and another one votes -2 in gerrit without issue in the patch. This is something that should just never happen. Thus PMC has to come with statement.
I guess Alex wanted to ask is we should not "down vote" patches to have more contributors.
So I would like to clarify that I'm not for "accepting any patches" as is in the mail title but rather about "non denying patches due to git history".
My point on the gerrit was that mass change patches without functional changes (or with questionable changes) are not acceptable because they make code maintenance harder due broken git blame.
I've made this -2 and -1 not because it is a matter of taste from me, which code style is better or not, but because code maintenance is also about understanding the history of the code, which is interrupted forever by such mass changes.
I observe the results of such patches in Platform UI project, which had numerous *non-functional* "code cleanups" behind it and now it is impossible to use git blame on affected code.
So all what I want is just to keep git history clean from non functional mass changes. I do not see how accepting non functional mass changes can attract more people.
I fully understand the usefulness of Git blame. But in my opinion is not the most valuable asset - people are so I'll ellaborate on that one.
Let's start with how non-functional changes help attracting more people. There are students in my team constantly - they go to university, they are taught the very last way of doing things, they try contributing to the project only to see that it's using "ancient" way of doing this - big minus point on "coolness" factor for the project, many give up on that point. Some decide that they will try it either way, by helping to "modernize" the project first (btw, most developers do that before working on a functional issue - bring it to a state where it's common to the rest of the codebase they see) - so their contributions are turned down cause they are "non-functional" - big minus poing on "openness" and "looking for help" factor for the project. Another big portion of potential contributors is gone.
Why do I speak of students here? Because this is the next generation of developers and projects that don't try to attract them are doomed to fail cause old times move on one by one and if there are not new people jumping in the maintenance burden becomes bigger and bigger to the state where it burn outs more people and lead to cases like this one where to reduce this burden people try to close contributions window even more leading to even further stagnation and the vicious circle grows.
Before anyone says this is hypothetical and theoretical - this is my experience with 10+ years experience with students in the team (not a single work day without one or more of them).
Now let's continue on how word spreads - this non-openness word spread way faster then effort to open it and leads to a state where even very experienced and part of the bigger community people (I am not putting names here on purpose but if anyone is interested I'll ask such well known people to jump in) simply deny trying to work with the project and rather workaround issues in their own plugins leading to inconsistency, partial features and breakages - all because they got tired of losing time on such discussion or even worse only heart about it from colleagues. And the story goes.
As an even additional thing - such changes are really good for people to get used to the procedures, code structure, find their path in source tree and etc. helping them create a better patch for a "functional" issue.
Kind regards,
Andrey Loskutov
Спасение утопающих - дело рук самих утопающих
http://google.com/+AndreyLoskutov
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc
