On Sat, 25 Feb 2017 17:03:58 +0200 Ivan Kalvachev <ikalvac...@gmail.com> wrote:
> On 2/25/17, wm4 <nfx...@googlemail.com> wrote: > > I'm documenting existing practice. > > > > I'm pulling the "6 months" timeout out of my ass, but I think it's > > pretty suitable. > > --- > > doc/developer.texi | 10 +++++++++- > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/doc/developer.texi b/doc/developer.texi > > index dbe1f5421f..41551498ad 100644 > > --- a/doc/developer.texi > > +++ b/doc/developer.texi > > @@ -338,13 +338,21 @@ you applied the patch. > > When applying patches that have been discussed (at length) on the mailing > > list, reference the thread in the log message. > > > > -@subheading Always wait long enough before pushing changes > > +@subheading Always wait long enough before pushing changes to code actively > > maintained by others > > Do NOT commit to code actively maintained by others without permission. > > Send a patch to ffmpeg-devel. If no one answers within a reasonable > > time-frame (12h for build failures and security fixes, 3 days small > > changes, > > 1 week for big patches) then commit your patch if you think it is OK. > > Also note, the maintainer can simply ask for more time to review! > > > > +@subheading Pushing patches without sending them to the mailing list > > +If you're the maintainer of a file, or the file is not actively maintained > > by > > +anyone, or the file is not covered by the MAINTAINERS file, you can just > > push > > +them without asking for permission, and without sending them to > > ffmpeg-devel. > > +This right only applies to developers with git push access, of course. > > +A maintainer is considered not active if he hasn't posted a mail to > > ffmpeg-devel > > +for longer than 6 months, and hasn't pushed a patch in that time period > > himself. > > + > > @subsection Code > > @subheading API/ABI changes should be discussed before they are made. > > Do not change behavior of the programs (renaming options etc) or public > > I object on this. > > I do prefer all the code to go though the maillist. > Even trivial changes. That doesn't reflect existing practice. I'm only documenting existing practice. If you want to change the rules, post a separate patch. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel