[Ffmpeg-devel] development policy change [RFC][PATCH]
Mon Jul 3 23:45:29 CEST 2006
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
> 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...
More information about the ffmpeg-devel