From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26839 invoked by alias); 18 Apr 2011 18:52:33 -0000 Received: (qmail 26523 invoked by uid 22791); 18 Apr 2011 18:52:32 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta07.emeryville.ca.mail.comcast.net (HELO qmta07.emeryville.ca.mail.comcast.net) (76.96.30.64) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Apr 2011 18:52:18 +0000 Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta07.emeryville.ca.mail.comcast.net with comcast id Z6XK1g0071vN32cA76sHa4; Mon, 18 Apr 2011 18:52:17 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta22.emeryville.ca.mail.comcast.net with comcast id Z6sG1g0090BKwT48i6sGXp; Mon, 18 Apr 2011 18:52:17 +0000 Subject: Re: [PATCH] doubled words Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mike Stump In-Reply-To: <8739lf7elo.fsf@rho.meyering.net> Date: Mon, 18 Apr 2011 19:03:00 -0000 Cc: Gerald Pfeifer , "gcc-patches\@gcc.gnu.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <87aafsq66f.fsf@rho.meyering.net> <892EA220-2EC7-4DAD-9089-73168984DB2A@comcast.net> <77B8DA3F-4856-435E-B7FB-09922B2775C1@comcast.net> <8739lf7elo.fsf@rho.meyering.net> To: Jim Meyering X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg01442.txt.bz2 On Apr 18, 2011, at 8:40 AM, Jim Meyering wrote: > If you hadn't said anything, I would have committed those typo fixes > by now, based on what I perceived as your review/approval and on my > reading of this part of http://gcc.gnu.org/svnwrite.html: >=20 > Free for all >=20 > The following changes can be made by everyone with SVN write access: >=20 > Fixes for obvious typos in ChangeLog files, docs, web pages, > comments and similar stuff. Just check in the fix and copy it > to gcc-patches. We don't want to get overly anal-retentive about > checkin policies. >=20 > If that policy is no longer in effect or does not apply here, > can you clarify or point to a more up to date policy? No. Doesn't exist. The webpage isn't maintained with the actual details..= . I'd say that, yes, the last bunch is fine to check in, IMHO. For the l= ib* and the */ changes, you'd need to break these down and have someone tha= t knows just what to do with each hunk review it. So, for example, the go = changes should go to Ian, and he can say, yes check them in, or more likely= , please submit/check them into the master go repo. The one in gcc is a sh= adow of the master. Just ping any patch you don't get approval for once a week, every week, unt= il approved or rejected.