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

[Michael Niedermayer]

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


> 
> > > > now one could add the new API, but not mark the old as
> > > > deprecated, but doing this means people will use the old in newly added
> > > > code, which is not good.
> > > > 
> > > > What both you and I seem to want is to hide the warnings about deprecated
> > > > stuff in existing code without hiding them for new code.
> > > > Maybe that could be done with some Makefile magic i dont know ...
> > > 
> > > I consider this a very bad idea.  Nobody will notice it and people will
> > > look at old files and copy it into their new files.
> > 
> > So what is it that you complain about, if its not that?
> 
> I'm complaining about deprecated functions not being replaced.

which functions?

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- 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/20090410/95ad0c9b/attachment.pgp>