From: Mark Mitchell <mark@codesourcery.com>
To: Steven Bosscher <stevenb@suse.de>
Cc: Jakub Jelinek <jakub@redhat.com>,
Matt Austern <austern@apple.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Committed] Use special-purpose hash table to speed up walk_tree
Date: Mon, 18 Oct 2004 04:19:00 -0000 [thread overview]
Message-ID: <41734039.8070006@codesourcery.com> (raw)
In-Reply-To: <200410171158.29730.stevenb@suse.de>
Steven Bosscher wrote:
>On Sunday 17 October 2004 07:51, Mark Mitchell wrote:
>
>
>>I don't think there is any such policy one way or the other. Certainly,
>>there is precedent for patches being approved offline.
>>
>>
>
>I know there is, and I think it's wrong. More eyes see more
>things.
>
>
Yes, but I do have the authority to approve patches. If we had a
no-offline-approval policy, what would have happenned is that Matt would
have posted the patch, and I would have immediately approved it. That's
no different that me approving the patch offline; we would still have
had a broken patch committed to the tree.
To make things more substantive, we could require that all patches be
posted for a period of time (24 hrs?) before being approved. That seems
silly though; some patches are very obvious. So, we'd have to make
judgement calls about what's appropriate in what situations. If I'd
anticipated problems, I would have just asked for further testing in the
first place.
In short, I don't see that there's a policy problem. If there's a
problem, it's just that I didn't anticipate the 64-bit mode issues, but,
hey, we all make mistakes.
>Can we make it a requirement that larger patches like this should
>be tested on three platforms when the mainline is in stage3?
>
>
I don't think this is a large patch. I actually thought it was pretty
straightforward. It did have a bug, but that happens sometime. I don't
think that requiring testing on three platforms for this kind of patch
would be profitable, overall.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
next prev parent reply other threads:[~2004-10-18 4:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-14 23:22 Matt Austern
2004-10-14 23:24 ` Phil Edwards
2004-10-15 0:04 ` Matt Austern
2004-10-16 10:17 ` Jakub Jelinek
2004-10-16 10:37 ` Steven Bosscher
2004-10-17 8:30 ` Mark Mitchell
2004-10-17 10:59 ` Steven Bosscher
2004-10-17 18:45 ` Matt Austern
2004-10-18 4:19 ` Mark Mitchell [this message]
2004-10-21 21:25 ` Gerald Pfeifer
2004-10-16 10:42 ` Jakub Jelinek
2004-10-16 11:49 ` Jakub Jelinek
2004-10-16 18:29 ` Matt Austern
2004-10-16 18:35 ` Richard Henderson
2004-10-16 18:37 ` Jakub Jelinek
2004-10-16 18:51 ` Richard Henderson
2004-10-16 19:15 ` Jakub Jelinek
2004-10-17 1:11 ` Richard Henderson
2004-10-16 18:14 ` Matt Austern
2004-10-18 14:48 Richard Kenner
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=41734039.8070006@codesourcery.com \
--to=mark@codesourcery.com \
--cc=austern@apple.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=stevenb@suse.de \
/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).