From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21415 invoked by alias); 31 Mar 2003 16:42:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21370 invoked from network); 31 Mar 2003 16:42:50 -0000 Received: from unknown (HELO disaster.jaj.com) (66.93.21.106) by sources.redhat.com with SMTP; 31 Mar 2003 16:42:50 -0000 Received: from disaster.jaj.com (IDENT:1002@localhost [127.0.0.1]) by disaster.jaj.com (8.12.8/8.12.8) with ESMTP id h2VH4pmt015148; Mon, 31 Mar 2003 12:04:51 -0500 Received: (from phil@localhost) by disaster.jaj.com (8.12.8/8.12.8/Submit) id h2VH4obb015147; Mon, 31 Mar 2003 12:04:50 -0500 Date: Mon, 31 Mar 2003 18:13:00 -0000 From: Phil Edwards To: Daniel Berlin Cc: Gerald Pfeifer , gcc@gcc.gnu.org, Fergus Henderson , Mark Mitchell , Gabriel Dos Reis Subject: Re: review process Message-ID: <20030331170450.GA15096@disaster.jaj.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-SW-Source: 2003-03/txt/msg01805.txt.bz2 Moving to gcc@. On Mon, Mar 31, 2003 at 11:06:50AM -0500, Daniel Berlin wrote: > > If we could > 1. Be okay with the idea that any patch not submitted in a reasonable > format (IE changelog + patch in message, or changelog in message + > attached file with patch), and with [PATCH] in the subject line, > wouldn't be tracked. This seems obvious. > 2. Be okay with the idea that: patches approved by people without > reasonable mailers (reasonable being those that can tell us whether a > message is a reply to another message), when it's not easily detectable > otherwise, will be assumed to not be approved. There are only two or three people in the MAINTAINERS file that have mailers like this. This sounds good too (democracy at work). > 3. Standardize the text + possible placement of approval messages. > > then I'm pretty sure i could auto-track missed patches. > > But it's worthless if we can't detect already-approved patches, thus > the need to come up with a format for approval messages. > > Obviously, i don't need something in some strict format, I just need to > be able to determine that a given message containing patch was approved > (or approved with changes, etc). Thus, simply saying that approval > messages should contain a line starting with "approved". Most such systems also have a "stop processing" keyword or phrase, e.g., approved thankyou J.Random User wrote: > Here's my patch, yadda yadda yadda. Please also consider a followup patch that makes this work on platforms which do not necessarily obey the laws of physics during runtime loading. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams