[FFmpeg-devel] [PATCH] doc: clarify development rules
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
> >> 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