From nobody Fri Nov 17 10:05:14 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SWswD1xzPz50mbD for ; Fri, 17 Nov 2023 10:05:16 +0000 (UTC) (envelope-from olivier.freebsd@free.fr) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [IPv6:2a01:e0c:1:1599::11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SWswC4Z6Rz4gBy for ; Fri, 17 Nov 2023 10:05:15 +0000 (UTC) (envelope-from olivier.freebsd@free.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=free.fr header.s=smtp-20201208 header.b="VkkcBK2/"; spf=pass (mx1.freebsd.org: domain of olivier.freebsd@free.fr designates 2a01:e0c:1:1599::11 as permitted sender) smtp.mailfrom=olivier.freebsd@free.fr; dmarc=pass (policy=none) header.from=free.fr Received: from ravel.localnet (unknown [90.118.140.172]) (Authenticated sender: olivier.freebsd@free.fr) by smtp2-g21.free.fr (Postfix) with ESMTPSA id B6AD9200587 for ; Fri, 17 Nov 2023 11:05:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1700215514; bh=D2ROkOy91N8soXi5RJniZ6QapYj1cqR5PTXbvlx4dqE=; h=From:Cc:Subject:Date:In-Reply-To:References:From; b=VkkcBK2/QdffwEid7J4kHzMfsGjxHTu8uGrn43EaNLvtvvuS4ewtrMdjLsH6RGzyl zIxUbkIQ4+HCvrQU3VAMaj0V/pNcFaeryXL/OobwQAzjr9oduuWMAwpbIym9JdOz0Z qx0y59CP9mL6Kuf6dUQIEVK/G423CIaeIqhDrOBYdMEE1D38GhpAPUc9WBubwkDBVg dQxoH4cY8kIgwqyN/6kTOvcWJ5sZml85UfWyYFbEbouTJjVnOTX3Jp/RS/7JrN6z/M 4yiEdnPtuMuAuOUG6bgrO1LUjNyk9tGG8c3kdAbQt9xxeC90cc0kMRAV0BmmtzCbww gfIaVh7g82JWw== From: Olivier Certner Cc: freebsd-stable@freebsd.org Subject: Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule Date: Fri, 17 Nov 2023 11:05:14 +0100 Message-ID: <2295486.mbH6SKH1i7@ravel> In-Reply-To: <20231116003030.GO1307@FreeBSD.org> References: <20231114203654.GB52320@FreeBSD.org> <20231116003030.GO1307@FreeBSD.org> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [0.99 / 15.00]; MISSING_TO(2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.89)[0.889]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[free.fr,none]; CTE_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:e0c:1:1599::11:c]; R_DKIM_ALLOW(-0.20)[free.fr:s=smtp-20201208]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[free.fr:dkim]; FREEMAIL_ENVFROM(0.00)[free.fr]; DKIM_TRACE(0.00)[free.fr:+]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[free.fr]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:12322, ipnet:2a01:e00::/26, country:FR]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4SWswC4Z6Rz4gBy X-Spamd-Bar: / Hi Glen, > I also agree we cannot prevent people from downloading the images, > installers, whatever before the announcement. That is the lovely race > condition with which we have to live at the moment. Yes, and given that, I don't think you did anything wrong. It seems that the race is the same for freebsd-update(8), according to "The Doctor". But maybe in this case it is easier to fix, perhaps if installing the metadata signaling the new release to it can be delayed, by contrast with big files containing the actual data (I don't know how freebsd-update(8) works, so this is just a guess). > The alternative would be to say nothing at all. I really hope you and re@ will never choose this way. > Either way, it is a productivity, communication drain. It is > a lose-lose situation no matter how one looks at it given the above > context. We either get chastised for being "too open" into insights > delaying an official announcement, or for being "not open enough" when > there is silence from RE when a release does not meet its scheduled > announcement date. IMHO, a delay should always be announced (perhaps unless it's only a few days). If it is too hard to decide on the right level of details, then only mention that some (potential or verified) problem is being looked upon, but don't let that prevent you from communicating. As for people saying that they have already installed the "release", I'd suggest to have some text on the website (https://www.freebsd.org/releng/ perhaps) explaining that images on mirrors can appear in advance of release announcements and that they should not be considered as official until the official mail is sent, and just kindly point them to it. I hope this can contribute to at least attenuating the drain you're experiencing. Regards. -- Olivier Certner