[Ffmpeg-devel] development policy change [RFC][PATCH]

[Diego Biurrun]

On Mon, Jul 03, 2006 at 01:03:33PM +0200, Michael Niedermayer wrote:
> 
> On Mon, Jul 03, 2006 at 12:39:53PM +0200, Reimar Doeffinger wrote:
> > Hello,
> > On Mon, Jul 03, 2006 at 11:52:55AM +0200, Michael Niedermayer wrote:
> > > +++ ffmpeg-doc.texi	(working copy)
> > > @@ -1271,7 +1271,10 @@
> > >     you applied the patch.
> > >  @item
> > >     Do NOT commit to code actively maintained by others without permission. Send
> > > -   a patch to ffmpeg-devel instead.
> > > +   a patch to ffmpeg-devel instead. If noone awnsers within a reasonable time
> > > +   (12h for build failure and security fixes, 3 days for all other small changes
> > > +    1 week for big patches) then commit your patch if you think its ok
> > > +    also note, the maintainer can simply ask for more time to review!
> > 
> > Agree (except s/awnser/answer/ and s/its/it is/ of course), though 1
> > week might be a bit short for big changes, esp. since the maintainer
> > might simply be on holiday (or should we make it overcomplicated and
> > introduce a maintainer-on-holiday mode :-P )
> 
> hmm the mainteiner might be 2 weeks on holiday too and we really shouldnt
> delay patches by months ...
> 
> my suggestion would be that maintainers could simply add a note into the
> MAINTAINERS file, like:
> iam on holiay until X, wait until X+1 week before commiting any big changes to
> my files
> 
> or
> 
> iam busy, post patches to ffmpeg-dev and if noone replies and you are sure
> your change is ok then commit in 2 days

Put the burden on the maintainer.  If he has a problem with somebody
committing to his code, then he can notify others of being away.

I'm OK with the patch as-is.

That said, I personally don't mind people committing to maintained code
as much as others.  Usually maintainers complain if something was bad or
could be done better and things get resolved quickly...

Diego