From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id qIF7N54/5mX7jwAAqHPOHw:P1 (envelope-from ) for ; Mon, 04 Mar 2024 22:39:43 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id qIF7N54/5mX7jwAAqHPOHw (envelope-from ) for ; Mon, 04 Mar 2024 22:39:43 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=GJGgjp6w; 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=1709588382; 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=gePYXxUqmK/Qmi7UeBVlltmXEIZ4U042Vs5KXpYfzio=; b=ZgLAQzBKswGqPkFBFf00tzeZFg9C37Sip9W+Rfq8NUvsDft5BJas9mOxvt0esWPuOttOo2 +cAGm1xRvDt47loXZzxpPh6nImTRaf167VyBUwusSmdN0bkiUgZx1w9fuuCa4NlMnbnkSl 5r1/V07tHOeoycPJR+HvkHs1qwa+WQL2PoWuD9jrwntwynsYbqr8MjiB+Ltv7AcB7j5qp2 CoJ6xDFfVOWUAACOAfLs8bvi19acqc+3D4m5nxDqad41qSun/Nln0+xkdWLjoZJJlMphy3 D0AzNLHBQEoqly4rSlKEDsi2yFqIWGxCzbxa87YM5uS3aHdxpZv9DANguRXeXQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=GJGgjp6w; 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=1709588382; a=rsa-sha256; cv=none; b=hrotDxswDXO7SSDIhsGouC3iJSlWOQPvl5DykFq4nZ4VQukKJnjreNV/ZYLg3j/BZQIKwQ lWsbJlNEHhUwJB+fVNYZGjPBrgc+aiayhImOSSrzXu0VEJel4gRXJLKvGxSOE2XC91pt0g 6GxkMUuoKZia5FKuhkX/t8xbhmkmoommt/eAVsmOEnbZIDc98szFgLc8YkHkuOGnXaZjGF ul4+IAQy+l/h5t62SC4SoWW0Sv0SIO9SVEjQHnpEmKVvRBeiM1xvEhA20+Cy+0+u8crdb6 DcydSVUFjcRNUwxPbuG1zZHiQ27/6bSQaD+Ottrp/d+chcdX1gWr67xMEKPJ6w== 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 C29F96AD50 for ; Mon, 4 Mar 2024 22:39:42 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rhG1b-00065J-C3; Mon, 04 Mar 2024 16:39:07 -0500 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 1rhG1Z-000658-CX for guix-devel@gnu.org; Mon, 04 Mar 2024 16:39:05 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rhG1X-0003LO-2z for guix-devel@gnu.org; Mon, 04 Mar 2024 16:39:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1709588338; x=1709847538; bh=gePYXxUqmK/Qmi7UeBVlltmXEIZ4U042Vs5KXpYfzio=; 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=GJGgjp6whzaMQdW6SLv/M6Pb7Xy7ys5Y0Ic/+S4p/usS34gfx4rOBc4MEAa+6WLnj enBCSu98gYvyuRtGIRI1XOQFURLk+nMDPyMzYasNRO1plJqDe2AxalU4sUZrSJq8Bx YNFCpiPqWRtOGtQTXzelp/7hpP0II1ccYPHVs89zJgqWXEWG50NVKiklt67xMSBHFf DWNgmHrHPqkGEiqtWGFt31+qXj5q0oeQhNTmplMYIloPen/RZRfKj0L+WoQ94zdcgL PMnG3OhvMPUbRf+ZrTwj6yYotl7S1jgbAjhXXI+3NXBdNtLAFc0Pbe/GmrsPmZbSKI s7ZU21LBDzIIQ== Date: Mon, 04 Mar 2024 21:38:36 +0000 To: Ricardo Wurmus From: John Kehayias Cc: Attila Lendvai , Philip McGrath , Saku Laesvuori , Liliana Marie Prikler , guix-devel@gnu.org, dan , 69461@debbugs.gnu.org Subject: Re: Should commits rather be buildable or small Message-ID: <87jzmhad9s.fsf@protonmail.com> In-Reply-To: <87fs09ar56.fsf@elephly.net> References: <6bcc9412f092c20fbd7f8326dbf91e90cef0eed1.camel@gmail.com> <875y16c54b.fsf@elephly.net> <87fs09ar56.fsf@elephly.net> 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.43.22; envelope-from=john.kehayias@protonmail.com; helo=mail-4322.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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-Migadu-Spam-Score: -8.13 X-Spam-Score: -8.13 X-Migadu-Queue-Id: C29F96AD50 X-Migadu-Scanner: mx11.migadu.com X-TUID: H8doO4dQWdQf Hi everyone, And sorry for reviving an old thread, but I am faced with a similar issue f= or updating vulkan, with the patch series submitted by dan (cc'ed): . I thought I would get some opinions here, ple= ase see below: On Mon, Dec 11, 2023 at 12:51 PM, Ricardo Wurmus wrote: > Attila Lendvai writes: > >> i myself also had headaches multiple times when i fixed something that >> needed to touch several different packages, and they would only work >> when applied in one transaction: >> In this case all the vulkan packages share a version through a variable nam= e. I would assume packages wouldn't like mixed versions, but maybe some wou= ld work (I haven't tried). I'll be taking this series on mesa-updates with = related changes, so the plan is that when it hits master there are no/few b= roken packages and full substitute coverage. So perhaps this makes this mor= e of a style and convention question. Some options: 1. Essentially squash to one commit where all of vulkan is updated in one c= ommit. The main upside is that nothing should break (within vulkan, depende= nts 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 has= hes don't match once variable is updated but package hasn't yet) versions a= re still mixed which is likely a problem. 3. Go with the series as proposed: this means after the first commit for su= re all other vulkan packages and dependents don't build, as the source hash= es won't match until the commit that updates that package. Along with versi= on mixing, this perhaps doesn't give you a helpful git bisect either? None are perfect. What do people think? My instinct is to go with the series as proposed (after review) accepting t= hat there will be for sure builds failing if time traveling to the middle o= f the series. I don't think we can really avoid that anyway, as sometimes w= e only see an issue after a commit and it is fixed some time later. We coul= d have a note in the first commit that this requires the next n commits to = update vulkan packages. That might help if someone is on an intermediate co= mmit and can see quickly in git log this note. Or perhaps we can note something is part of a dependent series when we make= commits so this is easier for someone to tell in general? Thanks! John