On Sat, 25 Feb 2017 21:23:27 +0100 (CET) Marton Balint <c...@passwd.hu> wrote:
> On Sat, 25 Feb 2017, Rostislav Pehlivanov wrote: > > > On 25 February 2017 at 18:35, Marton Balint <c...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel