[MPlayer-dev-eng] [PATCH] doc: update/clarify policy about mixing cosmetic and functional changes

Reimar Döffinger Reimar.Doeffinger at gmx.de
Mon Dec 12 23:44:46 CET 2011


On 12 Dec 2011, at 23:06, Alexander Strasser <eclipse7 at gmx.net> wrote:
> Clément Bœsch wrote:
>> On Mon, Dec 12, 2011 at 09:29:31AM +0000, Carl Eugen Hoyos wrote:
>>> Diego Biurrun <diego <at> biurrun.de> writes:
>>> 
>>>> -6. Do not mix cosmetic changes (indentation, function/variable renaming and
>>>> -   similar) with functional changes in a single commit. Instead, commit such
>>>> -   changes as a separate commit of their own.
>>>> +6. Do not mix large cosmetic changes (indentation, function/variable renaming
>>>> +   and similar) with functional changes in a single commit. Instead, commit
>>>> +   such changes as a separate commit of their own.
> 
>  This does still not forbid to do small cosmetic changes in separate commits.
> 
>>> I am against this change.
>>> The current variant looks good to me.
>> 
>> Haha :)
>> 
>> Well, I must admit it looks pointless to split in multiple commits for
>> very small indent changes, but this is so much bikeshed I don't think it's
>> worth trying to convince ppl.
>> 
>> OTOH I think a "at your own discretion" or similar should be OK; why not
>> allow developers to split if they want (even if "silly"), but not require
>> it (except for large ones)?
> 
>  +1
> 
>  This is exactly what I am trying to say. Leave it to the developer and don't
> flame developers for separating functional and cosmetic changes; even it it is
> a one liner.

Let's shorten that to "don't flame developers". Nagging is ok though, even if it is only nagging about having a different opinion.
Personally I considered it too bike-shed but since Diego seemed to care I just decided to follow his preferences.
I don't really like changing the text, though I did think about adding a disclaimer about the text not trying to list all corner-cases and that what matters in the end is listening to and coming to an agreement with your fellow developers.


More information about the MPlayer-dev-eng mailing list