[FFmpeg-devel] maintainer duties (was: Re: [PATCH] fix speex sample)

Michael Niedermayer michaelni
Sat Apr 11 05:48:07 CEST 2009


On Sat, Apr 11, 2009 at 03:42:04AM +0200, Diego Biurrun wrote:
> On Fri, Apr 10, 2009 at 10:48:36PM +0200, Michael Niedermayer wrote:
> > On Fri, Apr 10, 2009 at 09:01:36PM +0200, Diego Biurrun wrote:
> > > On Fri, Apr 10, 2009 at 08:45:41PM +0200, Michael Niedermayer wrote:
> > > > On Fri, Apr 10, 2009 at 08:28:19PM +0200, Diego Biurrun wrote:
> > > > > On Fri, Apr 10, 2009 at 07:38:48PM +0200, Michael Niedermayer wrote:
> > > > > > On Fri, Apr 10, 2009 at 07:26:56PM +0200, Diego Biurrun wrote:
> > > > > > > On Thu, Apr 09, 2009 at 04:15:01PM +0200, Diego Biurrun wrote:
> > > > > > > > 
> > > > > > > > I think maintainers should (in descending order of priorities)
> > > > > > > > 
> > > > > > > > 1) review patches,
> > > > > > > > 2) fix bugs and
> > > > > > > > 3) implement missing features
> > > > > > > 
> > > > > > > One thing I forgot:
> > > > > > > 
> > > > > > > 0) Keep their code working and current.
> > > > > > > 
> > > > > > > I mean things like exchanging deprecated functions for their
> > > > > > > replacements etc.
> > > > > > 
> > > > > > yes, let me just add that all the
> > > > > > 0..3 have their easy, hard and insanely hard to implement cases
> > > > > > 
> > > > > > and in the case of replacing old by new, if a single developer doesnt have
> > > > > > the resources to replace all instances by the new there are only 2 choices
> > > > > > left
> > > > > > A. do nothing, new code still will then use the old system
> > > > > > B. add the new and replace what can be replaced with the available resources
> > > > > > 
> > > > > > I think B is pretty much universally better
> > > > > 
> > > > > Replacing one function by another is not an insane amount of work, far
> > > > > from it.  On second thought, the burden should probably be on the person
> > > > > implementing the replacement.  We should not have deprecated cruft in the
> > > > > codebase.
> > > > 
> > > > Was there a function i deprecated but did not replace where a trivial
> > > > search and replace was sufficient?
> > > 
> > > Did any of them require considerable amounts of work?  I don't think so.
> > 
> > let me repeat my question, what are you talking about?
> > Its very obvious you dont want the issues (if they even exist) fixed
> > because otherwise you would have pointed to them by now
> 
> I have already pointed the functions out:
> 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-March/065629.html

but this is what i meant, its either things that have alraedy been fixed
or things that are non trivial to fix.
you said above
"Did any of them require considerable amounts of work?  I don't think so."

Whats left from this list needs considerable amounts of work

lets see whats in that list:

> Michael:
> libavformat/asfdec.c:364: warning: AVPaletteControl is deprecated
> libavformat/avidec.c:491: warning: AVPaletteControl is deprecated

we first need to decide how to put the palette info into the bitstream, also
fixing these 2 will require all decoders that support palettes from avi/asf
to be fixed at the same time as well.
no black magic but could certainly be called considerable amount of work


> libavcodec/bitstream.c:129: warning: ff_realloc_static is deprecated (declared at libavcodec/bitstream.c:53)

see below


> libavutil/random.h:55: warning: av_random_generate_untempered_numbers is deprecated (declared at libavutil/random.h:39)
> libavutil/random.h:73: warning: av_random is deprecated (declared at libavutil/random.h:50)
> libavutil/random.h:55: warning: av_random_generate_untempered_numbers is deprecated (declared at libavutil/random.h:39)
> libavutil/random.h:73: warning: av_random is deprecated (declared at libavutil/random.h:50)

these have been fixed already, and iam sorry that i did not do more
of these fixes myself, but i dont really remember anyone asking me to
and what you putted under my name was nonsense not fixable, as the whole
file should and was removed once it became unused.
You did not list the actual uses of av_random() that occured all over the
place under my name ...


> 
> Remaining deprecated functions are AVPaletteControl and ff_realloc_static,
> the latter is only used once even...

its used just once but to fix this each use of init_vlc() has to be changed
and in some cases in non trivial ways
I fixed some of these init_vlc cases, i did not fix all.
I was hoping the respective maintainers of the files would help ...
a grep INIT_VLC_USE_STATIC will show some of what need to be changed
but there are more init_vlc that just pass 1 instead of INIT_VLC_USE_STATIC
a
grep -A4 init_vlc libavcodec/*.c | grep '1 *)'
might catch some more ...

So next time you accuse me (and i am sure you will because it seems to be
poplar and the more polite i awnser the more people do)
maybe you should read and understand the code over which it is first.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090411/5665d683/attachment.pgp>



More information about the ffmpeg-devel mailing list