Re: [eclipse-pmc] Should we accept any patches to attract more contribut

["Daniel Megert" <daniel_megert@xxxxxxxxxx>]

> 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