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

wm4 nfxjfg at googlemail.com
Wed Mar 1 13:05:40 EET 2017

On Sat, 25 Feb 2017 21:23:27 +0100 (CET)
Marton Balint <cus at passwd.hu> wrote:

> On Sat, 25 Feb 2017, Rostislav Pehlivanov wrote:
> > On 25 February 2017 at 18:35, Marton Balint <cus at passwd.hu> wrote:
> >  
> >>
> >> On Sat, 25 Feb 2017, wm4 wrote:
> >>
> >> I'm documenting existing practice.  
> >>>
> >>> I'm pulling the "6 months" timeout out of my ass, but I think it's
> >>> pretty suitable.
> >>> ---  
> [...]
> > This is the way it has been done for years and its the way the project has
> > been able to move as rapidly as it has. That would slow down anything large
> > from being developed in the codebase, like encoders or decoders for a new
> > format, which are usually being developed by a single person who
> > understands the code better than anybody. I am okay with it being an
> > unwritten rule, anyone who needs to know about it knows about it and
> > everyone that knows about it knows that moderation is the key. But
> > forbidding it will kill the project.  
> I only want to have a chance to review before patches got pushed. I am not 
> saying we should explicitly demand a review for each patch. So this 
> normally should only cause any developer an additional sent email to the 
> ML and 1-2 days of delay. With git, I don't think this is that much 
> additional work.
> Of course, I could just subscribe to csvlog as well, and give post-commit 
> reviews if I want, it is just better to do it earlier, and less chance of 
> revert wars, because with the 'written' rule above I just as easily revert 
> anything in unmaintained code without a discussion, and remain within the 
> 'rules'.
> >> If this gets pushed, I am inclined to clean up the MAINTAINERS file and
> >> remove everybody who is no longer "active", and assume maintainership of
> >> parts I actively use and care about, but which has no maintainership
> >> anymore.
> >>  
> >
> > So you're okay as long as maintainers gets sorted out? You might as well do
> > it, its what's the file is supposed to reflect.  
> I still prefer if this is not applied. MAINTAINERS file might be cleaned 
> up regardless of this patch, however I think we should at least ping 
> everybody we are trying to remove from it.

As I said in another reply, I'm only documenting existing practice. We
can still change the rules in a separate patch (which of course will be
major drama etc. in which I don't necessarily want to be involved).

Or are there any doubts that this patch does what I claim it does
(documenting existing practice)?

Apart from that, I don't even know whether I can push this patch, or
what I have to do to get clear rejection/approval. The MAINTAINERS
file has ironically no maintainer.

So far, the score is 1 approval, and 2 invalid rejects. I guess I'll
push it on Friday morning if nobody rejects it by then.

More information about the ffmpeg-devel mailing list