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 694D640FCF for ; Sun, 2 Jan 2022 15:10:01 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C2BBF68B15B; Sun, 2 Jan 2022 17:09:58 +0200 (EET) Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 616DD68B010 for ; Sun, 2 Jan 2022 17:09:52 +0200 (EET) Received: by mail-qv1-f51.google.com with SMTP id fq10so28835239qvb.10 for ; Sun, 02 Jan 2022 07:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=Fq+aDTGo+Nw6FkHMFzkgWpSSXH9O+GkjrgfnX85Yvew=; b=dzZS/IQyEsnsyA7LP/nAAgk+yYmZPr2bjh0DyP6lsv07eXxmQtiJzlBWU/6Y7ERidA 0aClEHKt1GDhnDf+oEBIl8D/bNDrX0OZZUB/MhmQeNFCqMWp7ec3v5+0RPTNnu81z3vh dZGRPTgyPBcmjp1SH6y7NVtrEtu1/FKOs6piGQsD6Nd/9/14p/4yWqUTXl8/8iZLSJBH EXaqpWVszqyAUYsXjm7fQqyF3Lmoo15O4n74Yf/hREHZUHUrENOaJl9OnknxOPhbJPds dXq0Uh1Zv6j5jg+Bo60pDKuljztfwQQTtK/WPEuPlhAEHSvEZJLB8ugcS9QxyX/PFTkt rFeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=Fq+aDTGo+Nw6FkHMFzkgWpSSXH9O+GkjrgfnX85Yvew=; b=trl2Ky5qE4Ea6kibXG4iy/GA+LM9NaGncBKVrkk6Hw+MkQOLs3biouPybe/9MGQwVN eCaE7OXBwOFi0SYP1wKOVRvZYnyw8sJRb+N0amnTjThifGyin/Cnm5TzVuQa8ZKP+k/n nUmW8WMuHvtNjpr1+yUwIpC1mLFE0Ktb8fTOYWaF0ZhRn4OSmK7NSW8DeCjhoJr7+p0l sQfJ4c+erLipJ3KBgTzY876cLqPgCxN/lW3jq7/cr6+eOZft6Y+AHZ+rDLZkB6opRwWa ujowlCE7kW3IkVDfC43O8w90OLO5Q3R+LylKX1hYqgaEIqAI1EsEPPZNbiKWiF4yTe05 YPuA== X-Gm-Message-State: AOAM530ZIXVmfd0AYLkMzrGbIl0Qkh0bmtvY+tTKzJqw7FDx0RjB6Q5D O1kXKP3p1ZSlbvQPl5VazDsHdglb1gg= X-Google-Smtp-Source: ABdhPJxe4ZS+AugLVD+lz+2BNDXBY9+OUiehNhNO4nqMY7UaO4cbRX1UuTx/et3z2jLGQvUmy2AkIg== X-Received: by 2002:a05:6214:5096:: with SMTP id kk22mr39053791qvb.39.1641136190220; Sun, 02 Jan 2022 07:09:50 -0800 (PST) Received: from [192.168.1.55] ([191.83.210.83]) by smtp.gmail.com with ESMTPSA id m20sm27691071qtx.39.2022.01.02.07.09.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Jan 2022 07:09:49 -0800 (PST) Message-ID: <6700575c-8e6e-80e4-aedc-ca82c297e432@gmail.com> Date: Sun, 2 Jan 2022 12:09:48 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20211125171932.GC2829255@pb2> <164113275711.2375.2561092812450139105@lain.red.khirnov.net> <35404072.zGk2CCufKt@morningstar> From: James Almer In-Reply-To: <35404072.zGk2CCufKt@morningstar> Subject: Re: [FFmpeg-devel] 5.0 release 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 1/2/2022 11:50 AM, Zane van Iperen wrote: > On Monday, 3 January 2022 12:29:02 AM AEST James Almer wrote: > >>> There were some disagreements on IRC a few days ago about what should >>> and should not go into the release because of insufficient fuzzing and >>> the danger of introducing security issues. >>> >>> To avoid conflicts around this in the future, I'd suggest (for future >>> releases) to create the release branch a significant time (e.g. a month) >>> before doing the actual release. >>> >>> Opinions? >> >> It's a good idea, but we need to be strict about it. As in, we need to >> state that the moment the branch is made it's a definite feature freeze, >> and only fixes, documentation changes and similar may be cherry-picked >> into it (meaning nothing that usually comes with a version bump, even if >> micro), much like we do for a point release, even if the initial release >> was not tagged yet. >> > > I completely agree, this is a *very* good idea. If people treat it like > an existing release branch, i.e. only bugfixes, etc., then it would > save this from happening again. > > Also means there wouldn't need to be a "don't add big things" announcement > _somewhere_ on the ML. > >> Reverting something in the release branch is already going to be dirty >> no matter what, because we do a minor bump to ensure the release has its >> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking >> a demuxer available in lavf 59.12 > > Depends on what you mean by "lacking a demuxer"... One (hacky) option would > be to replace it with a stub implementation that always fails. Or tag it as experimental. > > Or we could just branch off at 7cee3b3718 and cherry-pick anything we need back. > There's only like four commits that need it (so far): 2f6360ff21, 9cfc7a2440, > c417616762, and d6b2357edd. Branching at 7cee3b3718 will give you a snapshot with lavf 59.10. What do you do with the release branch exclusive bump? Can't be 59.11 as that's in master post branch creation. Same with 59.12. So you have to do 59.13, but then the 59.13 feature set is that of 59.10, thus lacking the stuff added in 59.{11,12}, And that's a real pain in the ass for anyone looking at our versioning to know what they can expect from the libraries. The less-messy options at this point, besides your suggestion above or mine about tagging it as experimental, would be to revert the imf demuxer in master and then branch, or branch at the newest commit in the tree without a revert then delay tagging the release until a month has passed and the imf demuxer was tested somewhat (Which is what Anton suggested, but starting with this release instead). Also, unless ossfuzz compiles with libxml2 enabled, we're not going to see any kind of fuzzing for imf from it. > > > > > _______________________________________________ > 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". _______________________________________________ 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".