[FFmpeg-devel] [PATCH] ffv1enc: Make ffv1.3 non experimental

[Paul B Mahol]

On 8/18/13, Alexander Strasser <eclipse7 at gmx.net> wrote:
> On 2013-08-17 14:11 +0200, Michael Niedermayer wrote:
>> On Sat, Aug 17, 2013 at 11:22:19AM +0000, Paul B Mahol wrote:
>> > On 8/17/13, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > > On Sat, Aug 17, 2013 at 10:38:07AM +0000, Paul B Mahol wrote:
>> > >> On 8/17/13, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > >> > On Sat, Aug 17, 2013 at 09:29:35AM +0000, Paul B Mahol wrote:
>> > >> >> On 8/17/13, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > >> >> > The fate tests change as they used 1.2 previously
>> > >> >> >
>> > >> >> > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
>> > >> >> > ---
>> > >> >> >  libavcodec/ffv1enc.c          |    4 ++--
>> > >> >> >  tests/fate/vcodec.mak         |    2 +-
>> > >> >> >  tests/ref/seek/vsynth2-ffv1   |   40
>> > >> >> > ++++++++++++++++++++--------------------
>> > >> >> >  tests/ref/vsynth/vsynth1-ffv1 |    4 ++--
>> > >> >> >  tests/ref/vsynth/vsynth2-ffv1 |    4 ++--
>> > >> >> >  5 files changed, 27 insertions(+), 27 deletions(-)
>> > >> >> >
>> > >> >>
>> > >> >> So 1.2 coverage is now 0% ?
>> > >> >
>> > >> > testing should concentrate on non experimental variants.
>> > >> > 1.2 is experimental and cannot be used unless the user explicitly
>> > >> > enables experimental code.
>> > >> > That means noone should be using it, no files should exist in the
>> > >> > wild
>> > >> > and thus testing it probably makes no sense
>> > >>
>> > >> Ah. so previously 1.2 was tested for no reason at all?
>> > >
>> > > prior to 1.3 we tested 1.2
>> > >
>> > >
>> > >>
>> > >> What about 1.1 and older version coverage?, that's why original
>> > >> question...
>> > >
>> > > improving fates coverage was and is welcome
>> >
>> > Sorry but not me. You as mainter of ffv1 are first on line.
>>
>> maintainers review changes
>> maintainers integrate/merge/pull/cherry pick good changes
>> maintainers fix regressions and make sure the code is in good shape
>> and working
>> maintainers revert bad changes and they then flame thouse who did the
>> bad change
>
>   I consider the flaming part optional :)
>
>> maintainers might do alot more than that but adding every good idea
>> someone proposes is not their "duty" though of course they might
>> do it anyway
>
>   Also we have docs about maintaining written here since some time:
>
>   https://trac.ffmpeg.org/wiki/MaintainingFFmpeg
>
>   Maybe we should add reverting bad changes as an explicit
> bullet point there. Will do so, if no one has good reasons
> against it. It also kind of includes fixing regressions
> so I do not think we need to state that explicitly.

Looks like everybody missed real point. Without coverage
one can not found out if some change caused regression, and the
only way is if someone reports it.