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

Carl Eugen Hoyos ceffmpeg at gmail.com
Thu Mar 2 18:34:11 EET 2017


2017-03-01 13:31 GMT+01:00 wm4 <nfxjfg at googlemail.com>:
> 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?

Posting security issues and wait for comments does not seem
like a useful approach.

> I certainly hope you're not suggesting that security-sensitive changes
> to code the patch author does not maintain can be pushed without reviews
> at all.

I believe this is the established practice that you want to
document iiuc.

>> > 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".
>
> That's not what I wrote.

But this is how the change of text can be interpreted.

> It merely means that if you have showed no sign of activity after 6
> months, the timeout can be skipped.

As said, this is not a sufficient sign for non-maintenance.

>> > 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 patch did not change API (which would require the patch
sent to the mailing list) and vp56.c is not actively maintained, so
I don't understand what you are trying to say.

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

No, you misunderstand:
I am just pointing out that a pure time-out is not sufficient to
decide on maintenance.

> Please explain what the rules of this project are.

As you know, I disagree with several of the rules, and I have said so.
You have - afaict - agreed to them and I still feel that you prefer not
to obey. I have no idea what I can explain to you.

Generally, I honestly don't understand what you are trying to
achieve with your emails.

Carl Eugen


More information about the ffmpeg-devel mailing list