[FFmpeg-devel] [PATCH] doc: clarify development rules

[wm4]

On Sat, 25 Feb 2017 17:03:58 +0200
Ivan Kalvachev <ikalvachev at gmail.com> wrote:

> On 2/25/17, wm4 <nfxjfg at 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.
> >
> > - at subheading Always wait long enough before pushing changes
> > + at 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!
> >
> > + at 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.