Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-pmc] Should we accept any patches to attract more contributors?

I’m with Mickael here. Understanding the history is important, but not at the cost that code does not get improved to keep the history clean and short. Implementation patterns evolve and it is important to update patterns to a harmonic and modern style. It is also valuable to work on such changes for people who want to get into the development workflow and want to contribute changes with estimable risk. If we want to attract more developers to contribute, it should be acceptable to let them do code hygiene.

I also second that reading current code is more important than historic code.

Am 15.11.2018 um 10:49 schrieb Mickael Istria <mistria@xxxxxxxxxx>:


I think it's a sane discussion to have. There are pros and cons for both answers, and we probably need to be consistent about it to have the project being "fair" to all contributors.

On Thu, Nov 15, 2018 at 10:35 AM Andrey Loskutov <loskutov@xxxxxx> wrote:
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.

Looking at the history is an occasional activity; while looking at the current code is something many people do daily (I think I spend 60% of my day reading code, while I look a project history a few times a month).
So I personally am in the opinion that the state of current code is more important in term of maintenance than the state of the history, and that someone contributing such a mass change to improve current code is doing something good for the present and future of the project by making the code feel more welcoming and more maintainable (and probably better technically in case of isEmpty vs size).
For the history, things like git bisect can sometimes be an alternative where you need a git blame.

Of course, my comment applies only when the change is technically safe. For cases where the change introduce risk, we should first evaluate the risk and not merge risky parts unless they're proven to be fine.
eclipse-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top