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

[Michael Niedermayer]

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?


> 
> > 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?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

GMX, the mailprovider that uses RBL lists to reject mails from your friends
running their own mailserver at home. The mailprovider that obscures the
origin of mails (mis)identified as viruses. The mailprovider that improves
security my disallowing more secure forms of authentication.
-------------- 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/399a2691/attachment.pgp>