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? 
Hi again,

I know the discussion in this thread is over, but let me just add an observation:

For my investigations of a bug I frequently need an answer to the question:
What changes have been made to a given method ever since it was first created.

Several times since this thread I was unable to find an answer because of
commits like [1] (I have no intention of blaming Frederic Fusier :)).

In all those situations none of the hints nor enhancement ideas discussed in
this thread (would have) helped. Imagine a method of 100 lines of code.
Imagine, one in every three lines is changed by the clean-up. This implies
that the method is split into 67 chunks with different history. When using
blame annotations I need to inspect each of these 67 chunks. Next imagine
a method of 500 lines affected by the same clean up. ----  Please note,
that viewing the history of that file also is no good option, because it
may have hundreds of commits that didn't even touch the method in question.
As a result, in each of these situations I had to fix the current bug
while being unable to understand why the code looked the way it did.
This is an extremely uncomfortable situation. Those are code regions of a
complexity that no-one can fully understand without their history. Making
any changes in this situation is very prone to introducing more new bugs
than fixing old ones.

I'm just reporting this here, because I believe the discussion has either
underestimated the necessity of understanding code history, or overestimated
the options to filter out clean-up commits during investigation.

Note that I'm not arguing for stagnation, but anything that disturbs blame
usefulness must IMO demonstrate a substantial benefit beyond the level
of personal taste, or unproven assumptions.

best,
Stephan

[1] https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=bd6803034b95b7e0dd8c0cbcd0aead0a5c726f6

On 15.11.18 16:27, Thomas Watson wrote:

I agree with Lars, Alex and Dani.  Code clean-up should generally be accepted over maintaining git blame usefulness.

Tom

    ----- Original message -----
    From: "Daniel Megert" <daniel_megert@xxxxxxxxxx>
    Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
    To: eclipse-pmc@xxxxxxxxxxx
    Cc:
    Subject: Re: [eclipse-pmc] Should we accept any patches to attract morecontributors?
    Date: Thu, Nov 15, 2018 7:59 AM

    I generally agree with Lars and Alex as long as the clean-up is really improving the code (performance, readability, etc.). I
    would turn down clean-ups that just change the code based on personal taste.

    In the actual case I agree with the change for two reasons:

    1. It is easier to read (yes, personal opinion/taste).
    2. In many cases #isEmpty() is faster.

    Dani



    From: "Andrey Loskutov" <loskutov@xxxxxx>
    To: pmc <eclipse-pmc@xxxxxxxxxxx>
    Date: 15.11.2018 10:35
    Subject: [eclipse-pmc] Should we accept any patches to attract more        contributors?
    Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
    ------------------------------------------------------------------------------------------------------------------------------------



    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.
    I guess Alex wanted to ask is we should not "down vote" patches to have more contributors.

    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.

    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


    _______________________________________________
    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



_______________________________________________
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

Back to the top