On 25 February 2017 at 20:23, 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. > > Review or not, too slow still. If I have a fix for something I wrote and understand I'm not willing to wait and I'll push it, if I have some doubts I'll post it to the ML. You seem to give people way less trust than they deserve, especially if they have commit rights. I can't accept that. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel