[FFmpeg-devel] [PATCH v2 1/2] doc/developer: reword some of the policies

[Josh de Kock]

On 03/10/2016 00:05, Michael Niedermayer wrote:
> On Sun, Oct 02, 2016 at 11:16:49PM +0100, Josh de Kock wrote:
>>
>>
>> On 02/10/2016 22:47, Michael Niedermayer wrote:
>>> On Sun, Oct 02, 2016 at 01:51:41AM +0100, Josh de Kock wrote:
>>>> Explicitly state that FATE should pass, and code should work
>>>> for all reviewers who tested.
> [...]
>>>> - at item
>>>> -Do not commit unrelated changes together, split them into self-contained
>>>> -pieces. Also do not forget that if part B depends on part A, but A does not
>>>> -depend on B, then A can and should be committed first and separate from B.
>>>> -Keeping changes well split into self-contained parts makes reviewing and
>>>> -understanding them on the commit log mailing list easier. This also helps
>>>> -in case of debugging later on.
>>>> + at item Testing must be adequate but not excessive.
>>>> +If it works for you, others, and passes FATE then it should be OK to commit
>>>> +it, provided it fits the other committing criteria. You should not worry about
>>>> +over-testing things. If your code has problems (portability, triggers
>>>> +compiler bugs, unusual environment etc) they will be reported and eventually
>>>> +fixed.
>>>> +
>>>> + at item Do not commit unrelated changes together.
>>>> +They should be split them into self-contained pieces. Also do not forget
>>>> +that if part B depends on part A, but A does not depend on B, then A can
>>>> +and should be committed first and separate from B. Keeping changes well
>>>> +split into self-contained parts makes reviewing and understanding them on
>>>> +the commit log mailing list easier. This also helps in case of debugging
>>>> +later on.
>>>> Also if you have doubts about splitting or not splitting, do not hesitate to
>>>> ask/discuss it on the developer mailing list.
>>>>
>>>
>>>> - at item
>>>> + at item API/ABI breakages and changes should be discussed before they are made.
>>>
>>> I dont think this should list "breakages"
>>> "breakages" are a subset of "changes"
>>> and except in exteemly rare cases "breakages" should not happen
>>> intentionally
>>>
>>
>> That makes sense, I'll push a couple days with `s/breakages and //`
>> if there are no further comments.
>
> not sure this fits in the patchset but
> maybe "deprecation" should be added as deprecation implies future
> change. Such change of course needs to be discussed. Discussing it
> at the time of deprecation is better than after.
>

Applied without the deprecation addition.

-- 
Josh