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

Carl Eugen Hoyos ceffmpeg at gmail.com
Wed Mar 1 14:06:29 EET 2017


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).

> 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
maintainer".

> 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).

Carl Eugen


More information about the ffmpeg-devel mailing list