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



Am So., 16. Dez. 2018, 18:20 hat Stephan Herrmann <stephan.herrmann@xxxxxxxxx> geschrieben:
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

Back to the top