From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mav.lukeshu.com (mav.lukeshu.com [IPv6:2001:19f0:5c00:8069:5400:ff:fe26:6a86]) by sourceware.org (Postfix) with ESMTPS id 5CD2C3858C50; Wed, 12 Jun 2024 07:02:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5CD2C3858C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=lukeshu.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=lukeshu.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5CD2C3858C50 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:19f0:5c00:8069:5400:ff:fe26:6a86 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718175748; cv=none; b=uc6PiDAmeY80HPqB92NgKTUvsLUQoMoNtekV8uBdZin5M67aUvY16VjROCrjVvoqxJSy4NgLA8qi+aiRjowZnDyjMAtJeqzGDmXeJfw9FEEO3iG1V5VluIAdQMoHzGfEJDI7aFUtoQWcmxG6J9a5nsSragGSjFdPqG0uEpVXUxI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718175748; c=relaxed/simple; bh=Tiy7bbhQqcgpfZab+XiEGFdHYYQT1LQ8Di/VybdY8sQ=; h=Date:Message-ID:From:To:Subject:MIME-Version; b=E0eYTJPOpvB7tnNZIpc8ieqyjThZngk9dbgSIR8hHv56m14GgqEA7Ga1Ab1BliZpbhWxDWK0Y8myQFIfTc+LYDHbxVEUMpzhDArG+See3ZJP8wZ9EN8ZwxAJH9/fr4Mt9o9UkbFPkQl+HLIQIuFqw1VBnFVYgxUTEwNkjbcj3uA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from lukeshu-thinkpad-e15 (unknown [IPv6:2601:280:5e01:2a5d:aee0:10ff:fe55:8023]) by mav.lukeshu.com (Postfix) with ESMTPSA id 7B44B8067D; Wed, 12 Jun 2024 03:02:25 -0400 (EDT) Date: Wed, 12 Jun 2024 01:02:24 -0600 Message-ID: <87o786y77j.wl-lukeshu@lukeshu.com> From: Luke T. Shumaker To: Joseph Myers Cc: "Luke T. Shumaker" , binutils@sourceware.org, gdb-patches@sourceware.org, "Alfred M. Szmidt" , Ralf Wildenhues , Tom Tromey Subject: Re: [PATCH 4/4] Add a ./bootstrap script to automate bundling and generating files In-Reply-To: References: <20240606201145.1747021-1-lukeshu@lukeshu.com> <20240606201145.1747021-5-lukeshu@lukeshu.com> <5e24a41-524a-da55-bd5e-b8a0c23d360@redhat.com> <87bk4dduvt.wl-lukeshu@lukeshu.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.3 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 10 Jun 2024 13:27:51 -0600, Joseph Myers wrote: > On Fri, 7 Jun 2024, Luke T. Shumaker wrote: > > > Even after the two are in better sync, I think that having 'patches/' > > as a live a record of "changes that still need to be copied over" is > > probably a pretty good workflow; in many cases they can even be > > applied with `git am` and sent with `git send-email`. So, for > > example: whatever.patch is approved to binutils; and is commited to > > binutils.git/libiberty/patches/whatever.patch. That patch is then > > applied to GCC. The next time someone bumps the commit hash in > > binutils.git/bootstrap.d/bundle-gcc.mk ty sync with GCC, `patch` will > > complain that the patch has already been applied, and then the person > > can delete the patch file. > > That process still seems excessively complicated. > > Preferred process: > > * Precondition: the shared files and directories are in sync. > > 1. A patch is committed to both places. > > * Postcondition: the shared files and directories are still in sync. The problem with that is that the precondition is--at this moment--not met. Which is to say: Past attempts at this process have failed to fulfill the postcondition. > You seem to be suggesting a more complicated process involving committing > to one place, also committing a .patch file there, committing to the other > place, then doing a second commit to the first place to remove the .patch > file and update a commit hash. Mostly; but the last commit could be "lazy", the .patch files can stick around until the next time there's something to sync in the other direction. I'll admit, It's not a great process. But we've seen patches get lost-track-of, and never get synced to gcc. The process isn't *terrible*, and should make it so that things don't get lost track of and the postcondition isn't violated for as long. Anyway, my goal with this patchset isn't yet to induce any process change, it's to document how things are right now. > (Files such > as Makefile.def are definitely included in this, not just shared > subdirectories.) Oh shoot, I didn't realize that Makepkg.def is shared. I'll adjust the patchset in v3 to include it. -- Happy hacking, ~ Luke T. Shumaker