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 C585642C4C for ; Wed, 12 Jan 2022 23:17:56 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id ECCAA68A55A; Thu, 13 Jan 2022 01:17:53 +0200 (EET) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E1799689B39 for ; Thu, 13 Jan 2022 01:17:46 +0200 (EET) Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 01D8360004 for ; Wed, 12 Jan 2022 23:17:45 +0000 (UTC) Date: Thu, 13 Jan 2022 00:17:44 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220112231744.GK2829255@pb2> References: <20220108163012.GF2829255@pb2> <20220112163051.GJ2829255@pb2> <5d0d367d-c794-682f-febe-d167e828b316@gmail.com> MIME-Version: 1.0 In-Reply-To: <5d0d367d-c794-682f-febe-d167e828b316@gmail.com> Subject: Re: [FFmpeg-devel] 5.0 blocking issues 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: multipart/mixed; boundary="===============4068190757136295211==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4068190757136295211== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WrgD/HgqBLyzORPv" Content-Disposition: inline --WrgD/HgqBLyzORPv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 12, 2022 at 01:41:18PM -0300, James Almer wrote: >=20 >=20 > On 1/12/2022 1:36 PM, Nicolas George wrote: > > Michael Niedermayer (12022-01-12): > > > Iam really bad at keeping track of everything everyone asks to be > > > included and then notice when it was included fully with nothing > > > missing and no amendmends. > > > Maybe we could put a RELEASE_BLOCKER file in release branches in the = future > > > and everyone can list in it what needs to be done before the release > > > and when something is done the person pushing would also remove that > > > line from the file. > >=20 > > Maybe you could stop bothering about things you are not good at and that > > bore you. > >=20 > > If releases need to be made, then let somebody step in for the role of > > release manager. And if nobody steps in, let us not make releases. > >=20 > > After all, WE do not need to make releases: it is the other projects who > > need us to make releases. > >=20 > > Regards, >=20 > I think it should be more like, as release manager, he decides when to cu= t a > branch and when to tag a release within that branch, and in either case > giving a warning with some time in advance. Thats what i did in the past pretty much and iam more than happy with that. but this time things didnt work that well with the branch as there was some stuff people really wanted in. So i tried to be a bit more cautious with "just releasing". Also the channels waiting added delay at the start. I didnt say it previously but i think waiting for a feature like the channels API is a bad idea. If its ready, its ready if not i think we shouldnt connect releases to it and make it more constraint for everyone. > Saying "Anything else?" then waiting for people and constantly postponing > tagging is not going to work. And it's not the first time this happens. It didnt work very well here.=20 >=20 > Right now the branch is made and and the feature set frozen, and anything > that could be backported can wait until 5.0.1. Cutting the branch is when > interested parties should spoke and be hasty as that means a feature free= ze. > But right now, the release can and should be made whenever Michael wants = to. yes, you are correct, i agree, this whole thing here unneccesarily complica= ted things compared to past releases thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data --WrgD/HgqBLyzORPv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYd9hlAAKCRBhHseHBAsP q1HTAKCXKr4U/b4bjjmYINOG8Z3iL0FKhgCgmViA5wD1ui8vA/7l801WAmeN61Q= =bOz0 -----END PGP SIGNATURE----- --WrgD/HgqBLyzORPv-- --===============4068190757136295211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============4068190757136295211==--