From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from zero.zsh.org (zero.zsh.org [IPv6:2a02:898:31:0:48:4558:7a:7368]) by inbox.vuxu.org (Postfix) with ESMTP id DA7622161A for ; Sun, 28 Jan 2024 01:18:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-ID:Date: Content-Transfer-Encoding:Content-ID:Content-Type:MIME-Version:Subject:To: References:From:In-reply-to:cc:Reply-To:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=jCKqEdX0ODOt01H7p9+yjdCTw2ebM1XEvIF1ygGFcKU=; b=DqloqWuyMWspVSa5GdZG/bkyQ0 Nm7a1d5CwqZYrjYS25MtlLHeXzFGuIz7tn4naFnPPhqHTdun9hH86THUb422myP+bAoRuVu78KvrP bWhGpbva92y824TNLlsrcnkZcZoS9ZEg60FDQoCK3IjOI86eyp+SG3sKkuT3mA4PuxlrS5VXoh3xv HVSOll85h/x9TSvS0E8QJUkULC7K9dcDuZlwyPf0MMNbVCDjAgej0FudLjoaJZux6wWDDoEfLuvN+ W1rNPRzCAYduuf3vVZgabs+D2NDy6VIjNSeO7hhL5K2MNrozjsJvFQ1RbplZWcPRBWekYDNV03OWg 0eORMCvw==; Received: by zero.zsh.org with local id 1rTssb-000IHh-Gg; Sun, 28 Jan 2024 00:18:33 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1rTssM-000Hy5-UV; Sun, 28 Jan 2024 00:18:19 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.97.1) (envelope-from ) id 1rTssL-000000001P7-3YTW; Sun, 28 Jan 2024 01:18:17 +0100 cc: zsh-workers@zsh.org In-reply-to: <4jkxcveoznwk7zps3wfnoxwo4wcjitwkfjzzynidj2p2zntwpk@uiydkr3zltjw> From: Oliver Kiddle References: <8a1e39c6b8f061ce6d2e37c86e6d889309250f13.1704132620.git.joerg@jo-so.de> <2942-1706254789.333425@NzBz.rL2-.PsQC> <4jkxcveoznwk7zps3wfnoxwo4wcjitwkfjzzynidj2p2zntwpk@uiydkr3zltjw> To: =?utf-8?B?SsO2cmc=?= Sommer Subject: Re: [PATCH 2/6] lex: Mark variables with const init as const MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <5399.1706401097.1@hydra> Content-Transfer-Encoding: 8bit Date: Sun, 28 Jan 2024 01:18:17 +0100 Message-ID: <5400-1706401097.840562@Anqs.MZbL.6UYZ> X-Seq: 52507 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: Jörg Sommer wrote: > Yes, it's a kind of chicken egg problem. Either it gets a really big patch > or you have steps that introduce new warnings and solve them with later > patches. I don't know what you prefer for review. For now, I've applied those four (of the six) patches that don't introduce new warnings. > My main question is how this patch set should be organized? One commit per > file which reduces the number of warnings in this file to the cost of new > warnings in other files? Separating patches by source file is probably not the most helpful. I'd prefer if at least each patch series doesn't add new warnings so that we're leaving the source tree in a decent state when pushing. There might be some things that initially look like they clearly should be marked const but as the const percolates through you get stuck. Perhaps start with something like statusline, resolve the knock-on effects of marking that const and at that point finalise it as a single patch. If a subset of the changes can be applied standalone, consider separating that out. But really, whatever works for you is fine. Oliver