From: DJ Delorie <dj@delorie.com>
To: dje@transmeta.com
Cc: binutils@sources.redhat.com, cgen@sources.redhat.com,
sid@sources.redhat.com, gdb@sources.redhat.com
Subject: Re: New Sanyo Stormy16 relocations
Date: Tue, 17 Dec 2002 11:47:00 -0000 [thread overview]
Message-ID: <200212171947.gBHJl3P23665@envy.delorie.com> (raw)
In-Reply-To: <15871.31192.305439.813418@casey.transmeta.com> (message from Doug Evans on Tue, 17 Dec 2002 11:24:08 -0800 (PST))
> Having to get cgen approval for cpu-specific changes sucks.
> People should be able to police their own ports.
> gcc port maintainers don't have to get approval for changes to their
> ports. I don't understand why this would be any different.
Because cgen feeds binutils, gdb, and sid. Which one of those has the
port maintainers responsible for cgen? What happens if a binutils
maintainer changes cgen, and unknowingly breaks sid or gdb?
> But, if approval is required, methinks binutils is a better place to
> provide approval for .opc changes (e.g. complaints about warnings :-).
Better than sid? Better than gdb? OTOH we've talked about moving the
port-specific files out of cgen and into their own toplevel directory,
which would remove this issue anyway.
But, let me make the formal request anyway. gdb and sid cc'd.
Cgen folks (and others)... would it be acceptable to change the cgen
approval rules to allow people who could otherwise approve
port-specific patches in binutils, gdb, or sid, to be allowed to
approve port-specific changes in cgen as well?
next parent reply other threads:[~2002-12-17 19:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1039041358.28757.307.camel@p4>
[not found] ` <20021204225643.GS27956@bubble.sa.bigpond.net.au>
[not found] ` <1039043233.28767.313.camel@p4>
[not found] ` <200212170353.gBH3r9f14238@envy.delorie.com>
[not found] ` <15871.31192.305439.813418@casey.transmeta.com>
2002-12-17 11:47 ` DJ Delorie [this message]
2002-12-17 11:56 ` Frank Ch. Eigler
2002-12-17 12:09 ` Doug Evans
2002-12-17 12:14 ` Doug Evans
2002-12-18 2:37 ` Andrew Cagney
2002-12-18 7:47 ` Frank Ch. Eigler
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=200212171947.gBHJl3P23665@envy.delorie.com \
--to=dj@delorie.com \
--cc=binutils@sources.redhat.com \
--cc=cgen@sources.redhat.com \
--cc=dje@transmeta.com \
--cc=gdb@sources.redhat.com \
--cc=sid@sources.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).