[
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 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
