I know I am late to the discussion as well.
JDT core has always been conservative and less eager to change when it comes to things like this and I personally would like it to remain the same (Ironically, what Stephan pointed out is a JDT Core commit).
Nowadays, we only have JDT and not "JDT Core" and that kind of makes things a bit more difficult to control. But I assume that it won't be a problem if a project lead makes a call on changes like these, would it? I see that "generally accepted" leaves a lot of room for interpretation :)
Regards,
Jay
----- Original message -----
From: Lars Vogel <lars.vogel@xxxxxxxxxxx>
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
To: eclipse-pmc@xxxxxxxxxxx
Cc:
Subject: Re: [eclipse-pmc] Should we accept any patches to attract more contributors?
Date: Sun, Dec 16, 2018 11:44 PM
Hi Stephan,
To summarize the position of the PMC:
----
Code clean-up should generally be
accepted over maintaining Git blame usefulness.
----
Desired EGit enhancements were not part of that statement. We also did not assume that someone will short term work on these.
Best regards, Lars
I assume you are referring to a person desperately wanting
to push their cleanup commits. ;p
Stephan
On 16.12.18 18:15, Daniel Megert wrote:
>> didn't sound like this is s.t. we can expect anytime soon?
>
> I presume that if it is a major pain for someone, that person might start to work on this ;-).
>
> Dani
>
>
>
> From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
> To: eclipse-pmc@xxxxxxxxxxx
> Date: 16.12.2018 18:11
> Subject: Re: [eclipse-pmc] Should we accept any patches to attract more contributors?
> Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
> ------------------------------------------------------------------------------------------------------------------------------------
>
>
>
> Hi Dani,
>
> You're right, the proposals made by Sarika and you would help.
>
> Anything based on forward / backward navigation, OTOH, does not help
> to hide the Swiss cheese symptom.
>
> Let me just emphasize "would", because the assessment by Thomas Wolf
> didn't sound like this is s.t. we can expect anytime soon?
>
> Stephan
>
> On 16.12.18 17:59, Daniel Megert wrote:
>> Hi Stephan
>>
>> Don't you think
>>
>> _Bug 541236_ <https://bugs.eclipse.org/541236>: Improve EGit History and EGit Blame feature to act smartly on special commits
>>
>> would help here?
>>
>> Dani
>>
>>
>>
>> From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
>> To: eclipse-pmc@xxxxxxxxxxx
>> Date: 16.12.2018 16:48
>> Subject: Re: [eclipse-pmc] Should we accept any patches to attract more contributors?
>> Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
>> ------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> 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/andalsoon https://git.eclipse.org/r/#/c/131015/.
>>> I've rejected patch https://git.eclipse.org/r/#/c/132436/with-2and 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
>>>
>>
>> _______________________________________________
>> 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
>
>
>
>
> _______________________________________________
> 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
