[FFmpeg-devel] [PATCH] doc: clarify development rules
nfxjfg at googlemail.com
Wed Mar 1 14:31:02 EET 2017
On Wed, 1 Mar 2017 13:06:29 +0100
Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> 2017-03-01 12:36 GMT+01:00 wm4 <nfxjfg at googlemail.com>:
> > On Wed, 1 Mar 2017 12:20:10 +0100
> > Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> >> 2017-02-25 15:59 GMT+01:00 wm4 <nfxjfg at googlemail.com>:
> >> > I'm documenting existing practice.
> >> > - at subheading Always wait long enough before pushing changes
> >> > + at subheading Always wait long enough before pushing changes
> >> > to code actively maintained by others
> >> I suspect this is missing an exception for security issues if you want to
> >> document the actual practice.
> > I can add to the end of the subheading:
> > Critical security issues are an exception. These can be pushed after
> > the patch has been for 24 hours on the mailing list and the maintainer
> > didn't respond yet, and nobody has rejected the patch. In addition,
> > if another committer has approved the patch and acknowledged the
> > urgency of the fix, the patch can be pushed immediately.
> I will most likely not fix a (real) security issue, but above seems quite
> unpractical to me (and unreasonable for real security issues).
How is that impractical? What do you suggest?
I certainly hope you're not suggesting that security-sensitive changes
to code the patch author does not maintain can be pushed without reviews
> > Maybe a bit long, but should cover all bases.
> >> > + 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.
> >> Unfortunately, there are maintainers who are happy to review patches
> >> sent to improve their code but the files were not touched for more than
> >> six months so they did not seem active for more than six months.
> > So what is a reasonable method of determining whether a maintainer
> > is reachable?
> I fear there is no strict definition, patches can always be reverted though
> if a maintainer requests that.
> I am just (slightly) against writing "after six months, you are no more a
That's not what I wrote.
It merely means that if you have showed no sign of activity after 6
months, the timeout can be skipped.
> > The worst part is that not even "active" maintainers always respond,
> > even if you go a timeout.
> Then you push after the timeout (if no delay was requested).
michaelni didn't wait when pushing his vp56.c patches (didn't even send
them to the mailing list), even though it was a mid-sized (i.e. not
small) change. The maintainer of vp56.c is still reachable by mail, but
hasn't posted or contributed anything to ffmpeg in 3.5 years. michaelni
didn't wait for the timeout, which does not match with what you seem to
Please explain what the rules of this project are.
More information about the ffmpeg-devel