From: Alan Modra <amodra@gmail.com>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: binutils@sourceware.org, gdb@sourceware.org
Subject: Re: Maintenance of top-level files
Date: Fri, 10 Sep 2021 14:28:27 +0930 [thread overview]
Message-ID: <YTrl854dWOPm+5TF@squeak.grove.modra.org> (raw)
In-Reply-To: <20210908082349.GC1487362@embecosm.com>
On Wed, Sep 08, 2021 at 09:23:49AM +0100, Andrew Burgess wrote:
> My question then, is what are peoples thoughts on how these files
> should be managed?
The question I take it really is: Who has authority to approve
patches, and at least some responsibility to respond to bug reports
related to these files?
I don't think we (binutils + gdb) should take the position that these
files are owned by gcc, and thus authority and responsibility fall to
the listed gcc build machinery maintainers. That doesn't seem fair or
reasonable. The situation with top level files is very different to
say, libiberty, where binutils+gdb is unlikely to want changes that
are completely uninteresting to gcc. With top level config*, Make*,
libtool.m4, lt* and so on we often want changes that aren't
interesting to gcc, and vice versa. A model where changes are
installed first into one repository and then backported to the other
makes sense, I think.
So do we want someone appointed top-level build machinery maintainer
in binutils+gdb? If so, I nominate Simon Marchi if he's interested.
Why Simon? Because in digging through top-level logs, he's the most
recent (2018) person to act as a maintainer of those files, commit
d0ac1c4488. Before that, there was Ralf Wildenhues in 2010.
> Are we going to try and get back in step with gcc?
I think we should try to do that.
--
Alan Modra
Australia Development Lab, IBM
next prev parent reply other threads:[~2021-09-10 4:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-08 8:23 Andrew Burgess
2021-09-08 20:18 ` Mike Frysinger
2021-09-10 4:58 ` Alan Modra [this message]
2021-09-10 14:35 ` Simon Marchi
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=YTrl854dWOPm+5TF@squeak.grove.modra.org \
--to=amodra@gmail.com \
--cc=andrew.burgess@embecosm.com \
--cc=binutils@sourceware.org \
--cc=gdb@sourceware.org \
/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).