From: Joseph Myers <josmyers@redhat.com>
To: "Luke T. Shumaker" <lukeshu@lukeshu.com>
Cc: binutils@sourceware.org, gdb-patches@sourceware.org,
"Alfred M. Szmidt" <ams@gnu.org>,
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>,
Tom Tromey <tromey@redhat.com>
Subject: Re: [PATCH 4/4] Add a ./bootstrap script to automate bundling and generating files
Date: Thu, 6 Jun 2024 20:57:26 +0000 (UTC) [thread overview]
Message-ID: <5e24a41-524a-da55-bd5e-b8a0c23d360@redhat.com> (raw)
In-Reply-To: <20240606201145.1747021-5-lukeshu@lukeshu.com>
On Thu, 6 Jun 2024, Luke T. Shumaker wrote:
> * config/patches/
> * libdecnumber/patches/
> * libiberty/patches/
In my view, rather than maintaining binutils-local patches to these
directories, we should treat GCC and binutils as equally canonical for
them; any change approved and applied in one tree but not the other should
be treated as thereby approved for the other tree as well, and get
committed there (post to the relevant patches list and commit, without
seeking separate approval). That way, the only differences between the
two trees should be in the ChangeLog files (reflecting when changes were
applied to the two trees).
The same applies to files at top-level present in both trees, except for
ChangeLogs, README, MAINTAINERS and SECURITY.txt which are genuinely meant
to be different: any difference between other top-level files in the two
trees is a bug that should be reconciled by ensuring all patches have been
applied to both places. Also to files (other than ChangeLogs) in include/
that are present in both trees (but some files in include/ are
legitimately present only in one of the two trees).
Effectively, rather than treating GCC as the upstream for any files, treat
it as indicating a bug if GCC and binutils-gdb differ for various files -
including toplevel ones that actually come from other sources such as
libtool - but with neither tree as upstream of the other.
(Special-case exception: if one of binutils-gdb and GCC has updated
autoconf/automake/libtool and the other one hasn't updated yet, there may
temporarily be differences in such files - though if a change to work with
newer versions of autoconf/automake doesn't break older versions, it
should be applied to both trees. This exception is because such updates
can be complicated, so are more likely to happen if only one tree needs
updating at a time.)
--
Joseph S. Myers
josmyers@redhat.com
next prev parent reply other threads:[~2024-06-06 20:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 20:11 [PATCH 0/4] " Luke T. Shumaker
2024-06-06 20:11 ` [PATCH 1/4] readline: Fix examples/rlfe/configure.ac Luke T. Shumaker
2024-06-08 18:25 ` Maciej W. Rozycki
2024-06-08 18:28 ` Maciej W. Rozycki
2024-06-10 3:01 ` Luke T. Shumaker
2024-06-10 16:51 ` Simon Marchi
2024-06-06 20:11 ` [PATCH 2/4] Update COPYING files from gnu.org Luke T. Shumaker
2024-06-06 20:11 ` [PATCH 3/4] zlib: Remove files that should certainly not be checked in Luke T. Shumaker
2024-06-07 6:24 ` Jan Beulich
2024-06-07 7:53 ` Luke T. Shumaker
2024-06-10 3:04 ` Luke T. Shumaker
2024-06-08 0:35 ` Luke T. Shumaker
2024-06-06 20:11 ` [PATCH 4/4] Add a ./bootstrap script to automate bundling and generating files Luke T. Shumaker
2024-06-06 20:53 ` Luke T. Shumaker
2024-06-06 20:57 ` Joseph Myers [this message]
2024-06-07 8:23 ` Luke T. Shumaker
2024-06-10 19:27 ` Joseph Myers
2024-06-12 7:02 ` Luke T. Shumaker
2024-06-12 12:58 ` Tom Tromey
2024-06-06 20:55 ` [PATCH 0/4] " Luke T. Shumaker
2024-06-10 3:08 ` [PATCH v2 0/5] " Luke T. Shumaker
2024-06-10 3:08 ` [PATCH v2 1/5] readline: Fix examples/rlfe/configure.in Luke T. Shumaker
2024-06-10 22:49 ` Hans-Peter Nilsson
2024-06-10 3:08 ` [PATCH v2 2/5] Update COPYING files from gnu.org Luke T. Shumaker
2024-06-10 3:08 ` [PATCH v2 3/5] zlib: Remove files that should certainly not be checked in Luke T. Shumaker
2024-06-10 3:08 ` [PATCH v2 4/5] readline: Re-generate configure Luke T. Shumaker
2024-06-10 3:08 ` [PATCH v2 5/5] Add a ./bootstrap script to automate bundling and generating files Luke T. Shumaker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e24a41-524a-da55-bd5e-b8a0c23d360@redhat.com \
--to=josmyers@redhat.com \
--cc=Ralf.Wildenhues@gmx.de \
--cc=ams@gnu.org \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=lukeshu@lukeshu.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).