[FFmpeg-devel] [PATCH] doc: clarify development rules
nfxjfg at googlemail.com
Sat Feb 25 17:13:04 EET 2017
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.
More information about the ffmpeg-devel