From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id E06064484B for ; Fri, 28 Oct 2022 21:08:21 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C6C6C68BC10; Sat, 29 Oct 2022 00:08:17 +0300 (EEST) Received: from w4.tutanota.de (unknown [81.3.6.165]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7EF3568BA39 for ; Sat, 29 Oct 2022 00:08:10 +0300 (EEST) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w4.tutanota.de (Postfix) with ESMTP id 311EC1060277 for ; Fri, 28 Oct 2022 21:08:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1666991289; s=s1; d=lynne.ee; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=k6AOup1C7OEAU3UgDvFc7IXv0i4bBLqP2vKqaj7oWIc=; b=UiQd5awesxEbXd52tVZ43QmGmhS9+1WMgVyVZHuu2FFlgkFQz2WOZjeZf1l4YRXR 1b4fN7EGPG6jMzMiolTHwxdmB8xeh1rs0S/Xb/Zy/NIU8CTZI9dWyQQd8LEA6dhLmFK Z4rCr197pDfU76hSvonC9KkTKk22Ipgo/cN+rFBOULodp4LSfad5iHH6NjPMmVpz7qZ 20k+o5HAix5NpffAZMVstW8g2f/T31llI2mHMYiEO2jg6p81JYp8L1FqdobiOUc7mhg OJMTZCHVSFndbfFiGTOg8Rbp8b82VAEo1im50bNyMxqhv26KLHUML+v/iGfWzJQkdzV wiNh9cCvgQ== Date: Fri, 28 Oct 2022 23:08:09 +0200 (CEST) From: Lynne To: FFmpeg development discussions and patches Message-ID: In-Reply-To: <20221027164524.GL4048421@pb2> References: <20221024074221.217-1-d.kozinski@samsung.com> <5612537e-7e68-ee4c-17cd-30a42980915c@gmail.com> <20221027164524.GL4048421@pb2> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Oct 27, 2022, 18:45 by michael@niedermayer.cc: > On Tue, Oct 25, 2022 at 01:17:15PM +0200, Lynne wrote: > >> >> >> >> Oct 24, 2022, 18:29 by jamrial@gmail.com: >> >> > On 10/24/2022 12:56 PM, Lynne wrote: >> > >> >> Oct 24, 2022, 09:42 by d.kozinski@samsung.com: >> >> >> >>> - Changelog update >> >>> - MAINTAINERS update >> >>> >> >>> Signed-off-by: Dawid Kozinski >> >>> --- >> >>> Changelog | 3 ++- >> >>> MAINTAINERS | 5 +++++ >> >>> 2 files changed, 7 insertions(+), 1 deletion(-) >> >>> >> >>> diff --git a/Changelog b/Changelog >> >>> index ec9de1bd85..19e9ae3b1f 100644 >> >>> --- a/Changelog >> >>> +++ b/Changelog >> >>> @@ -45,6 +45,8 @@ version 5.1: >> >>> - remap_opencl filter >> >>> - added chromakey_cuda filter >> >>> - added bilateral_cuda filter >> >>> +- eXtra-fast Essential Video Encoder (XEVE) >> >>> +- eXtra-fast Essential Video Decoder (XEVD) >> >>> version 5.0: >> >>> @@ -92,7 +94,6 @@ version 5.0: >> >>> - anlmf audio filter >> >>> - IMF demuxer (experimental) >> >>> - >> >>> version 4.4: >> >>> - AudioToolbox output device >> >>> - MacCaption demuxer >> >>> diff --git a/MAINTAINERS b/MAINTAINERS >> >>> index eebfa5cfb7..df8d8eca73 100644 >> >>> --- a/MAINTAINERS >> >>> +++ b/MAINTAINERS >> >>> @@ -200,6 +200,8 @@ Codecs: >> >>> libvpx* James Zern >> >>> libxavs.c Stefan Gehrer >> >>> libxavs2.c Huiwen Ren >> >>> + libxevd.c Dawid Kozinski >> >>> + libxeve.c, Dawid Kozinski >> >>> libzvbi-teletextdec.c Marton Balint >> >>> lzo.h, lzo.c Reimar Doeffinger >> >>> mdec.c Michael Niedermayer >> >>> @@ -420,6 +422,9 @@ Muxers/Demuxers: >> >>> dv.c Roman Shaposhnik >> >>> electronicarts.c Peter Ross >> >>> epafdec.c Paul B Mahol >> >>> + evc.c, evc.h Dawid Kozinski >> >>> + evcdec.c Dawid Kozinski >> >>> + evc_parser.c Dawid Kozinski >> >>> ffm* Baptiste Coudurier >> >>> flic.c Mike Melanson >> >>> flvdec.c Michael Niedermayer >> >>> >> >> >> >> Nak, that list is only for those with push access, and no >> >> other changes may be made in the same patch. >> >> >> > >> > No, it's the other way around. Those in this list may be eligible for push access. >> > Being listed here gives them the right to NAK a patch made for a module they maintain, as well as their approval being (ideally) a requirement before making changes to it. >> > >> >> Nope. Michael will give anyone on the list push access. >> > > I have the feeling you dont trust me > if thats the issue, 2 lists will not fix that > I trust you more than others. But in this case, I simply don't understand. > The idea is that each developer who takes care of a bit of the code base > (reviewing patches, approving them, fixing issues, adding features, ...) > has the same rights as others. > That is git write, the list is the MAINAINERs list. > > Its not really true that everyone in that file has write access because > some people where forgotten and never asked, some simply dont know git well > enough, some explicitly said they do not want git write, some sent a lot of > messy patches and gave me pause so i didnt offer it and they also didnt ask. > The list should be pretty close though, these are all exceptions not the rule. > The maintainers list used to be what jamrial said it was - an informal list of those with good knowledge on a piece of code to make a review, independent of whether they had push access or not. This is also how users/casual patch senders treated it as - they added their name if they felt like they would like to be consulted on. The list is always a bit outdated, and that's okay. You started treating it as a formal list of those with commit access, and it's been somewhat chaotic. Users still think it's an informal list, developers still think it's an informal list, only you seem to think it should be more formal. When a user submits a patch, I wonder if they're asking for push access or do they simply want to be consulted on for future patches? More often than not, it's the latter. I think there should be 2 lists, and if someone wants push access, they should just send a patch requesting it directly rather than using the vague maintainer term that no one pays attention to. If someone thinks they should have push access and ask, then they probably need it. The maintainers list could continue to be treated the same way it's been treated. > I fail to see the problem, btw. > A Problem would be if someoe does something that requires to remove his git > write or that requires us to think about "should we close that write account" > (and yes i ignore here cases where core developers dont get along, thats not > a issue for a maintainer/git write list) > If we do not hit a situation where we consider closing an account then IMO > we havnt really had a problem with giving write access out too liberal. > The other side OTOH certainly has occured, people sending patches over and > over again, pinging over and over again and finally the patch is found to be ok > and applied. That would point more toward too little write permission, or at least > not the right person having write access, or a lack of incentives to review and apply > patches > I really don't think push access should be removed from someone inactive, but I also don't think it should be given to someone with zero commits just because their patches never got a response, like with this patch. For such a large and wanted feature, it'll get merged by one of us eventually. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".