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

[Alexander Strasser]

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.

  Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130818/d8cb393a/attachment.asc>