From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id gHn9K2zQAGblgwAAqHPOHw:P1 (envelope-from ) for ; Mon, 25 Mar 2024 02:16:28 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id gHn9K2zQAGblgwAAqHPOHw (envelope-from ) for ; Mon, 25 Mar 2024 02:16:28 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=RZ7FYSPr; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=quarantine) header.from=protonmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1711329388; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=479Ljh3dyhwM6psoA/Y/PQ21Bl9N2N2blEWm1JD1HAw=; b=iUQt+gGw6Y+K4dRalZuWqcCOjzJCO74WvIfctHHWLhi9nEgUD4C7Qani5IDzq8r1SPIozF /w0iD0uPoF+hutNsZ+HUacYshSX+NF8Mr/II5eDhC1vLuR7vtYtW+PrnjHu6eQxcIcX9F+ Xaafn9rtugdOMF8ZwIC54VRoGXhocPOwDtB2/ZZz8v/7uiVoavqt+9arShaz51I6i4W4Gq sb8NgWszvB9FwUr3IjS0ISLI57oxeFmuP9gvwdUQQsAsuxNc346fKZLXeEEueUs+Muhq1s oVgp385qfwXSdJr9FCOifuxTDwUJ8ZEav4nBbgVtc3cUCVJja7kuq5v1lkf6CQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=RZ7FYSPr; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=quarantine) header.from=protonmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1711329388; a=rsa-sha256; cv=none; b=EAXQw6BoFnrLE4X0U5jBDuHokmWSJaWNOnYUZdWXP4QQIT4AToxvrJxzZvjG+qdGFkZcO5 3fjgu13X9EMk7YtkJZ1hu6SXe3Pt9a8a69lKdo0SKMtfLzQpU8bjAEKzSlpaUQXTovzbvI KpUp/gHUaX9zAB6z9Zc25fgs+F2csb+Rj+xSM5LYkrIiRUQyCWC4fdy0dLZD+JKVzEuqFd JORX6Vn9O2G9bP6b3Lo/2rUGs5ASL8oL6ai13LFwf7dhBw0qUU5e6MPDLCy2Zt+CWBZ2f9 Zq1sykshhAPh37Kw2PGgDT2Z8ByuMpZzMWHM91dqJVn+7uQKGedyJbyY00F2hw== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A0DFB414E9 for ; Mon, 25 Mar 2024 02:16:28 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1roYwS-0001dk-0h; Sun, 24 Mar 2024 21:16:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1roYwN-0001dR-0v for guix-devel@gnu.org; Sun, 24 Mar 2024 21:15:55 -0400 Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1roYwL-0000rW-1x for guix-devel@gnu.org; Sun, 24 Mar 2024 21:15:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1711329349; x=1711588549; bh=479Ljh3dyhwM6psoA/Y/PQ21Bl9N2N2blEWm1JD1HAw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=RZ7FYSPrpaoW+NK5D1Vt+v+rzHlBERa9CXbJd35G5Y70k85sCOuUwzyTR0Xi6C80j Rh2s37sjiBciZ9/gp07hpuxt4IFg4PDy1EXNR0jPkl3OFTsMaT0JXdaf2kXsyJ2ZHn wwyWoqAEXwlCLhXIsa60xyIfgfCI1bTLmqMonuBN2g8vl37+j7qWUmfslSjulTuYOc d7JyzPucbBUWEwU5/77zJWo4BGPKS44ysGQx1wrUfpOxvGl7cHoXycjUZMIPnoYcm4 pmKyFuytAW9OlUQsbIz8jCi6uUMEXf2OXSdyVmxDns4iRgWBusgcihpzxk8irVj0hS TSLtoW2eZgrcA== Date: Mon, 25 Mar 2024 01:15:42 +0000 To: Liliana Marie Prikler , dan From: John Kehayias Cc: Ricardo Wurmus , Attila Lendvai , Philip McGrath , Saku Laesvuori , guix-devel@gnu.org, 69461@debbugs.gnu.org Subject: Re: Should commits rather be buildable or small Message-ID: <87y1a7nmbx.fsf@protonmail.com> In-Reply-To: References: <875y16c54b.fsf@elephly.net> <87fs09ar56.fsf@elephly.net> <87jzmhad9s.fsf@protonmail.com> Feedback-ID: 7805494:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.134; envelope-from=john.kehayias@protonmail.com; helo=mail-40134.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -8.20 X-Migadu-Queue-Id: A0DFB414E9 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -8.20 X-TUID: qqV42gGyHWLX Hi, Apologies for the delay. I would like to get things rolling on mesa-updates and building, including the vulkan updates, so a choice will have to be made :) Thanks for the input so far! On Tue, Mar 05, 2024 at 06:19 AM, Liliana Marie Prikler wrote: > Hi, > > Am Montag, dem 04.03.2024 um 21:38 +0000 schrieb John Kehayias: >> [...] >> 1. Essentially squash to one commit where all of vulkan is updated in >> one commit. The main upside is that nothing should break (within >> vulkan, dependents to be fixed as needed) and it shows as "one" >> change; the main downside is that the proposed changes are not just >> trivial version bumps. Harder to then disentangle as needed. >> >> 2. Make each commit updating a package, but don't use the variable >> %vulkan-sdk-version, updating each package with a version as it is >> done. Then do a commit where all the versions are replaced by the >> variable. This seems like unnecessary work to me and while it stops >> the obvious breaking (source hashes don't match once variable is >> updated but package hasn't yet) versions are still mixed which is >> likely a problem. >> >> 3. Go with the series as proposed: this means after the first commit >> for sure all other vulkan packages and dependents don't build, as the >> source hashes won't match until the commit that updates that package. >> Along with version mixing, this perhaps doesn't give you a helpful >> git bisect either? >> >> None are perfect. What do people think? > I think 1 would be workable if the changes to the packages are minimal. > You should also check whether you can just do the version bumps and > then the other changes =E2=80=93 or flip the order. > As currently proposed, the changes are not minimal. dan: Do you know if just a version/hash bump is at least buildable? Or are the changes necessary for the packages to build/function at all? Or I guess if the non-version changes are applicable to the current version first? > I don't really see the benefit with 2. Normally, we'd have "-next" > variants to catch nontrivial updates (among other things), but those > don't seem a good approach here. > > If nothing else works, 3 is indeed an option to fall back to, albeit > begrudgingly. As noted for 1, you could check whether bumping all the > hashes and then only fixing whatever else for the builds is an option > here. > That's what I'll have to do I think, unless indeed the versions changes can be made separately and still build. I can mark each patch in the commit log that it is part of a series updating all the vulkan packages. That might be something worth doing in general for cases like this, to help out future time travelers and when e.g. searching the log and finding a commit. > Alternative 4 would be to build those -next variants and then replace > the base vulkan all at once. This has the advantage of not doing any > version mixing in-between IIUC. > That's also an idea. Add a %vulkan-version-next or something like that, and -next variants of all the packages using that version instead. A bit clumsy and perhaps convoluted with the extra work for maybe minimal gain. I'll wait to see if dan has any information of what changes can be made independently, but I guess I'll just have to make a decision on mesa-updates. Thanks! John