From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10311 invoked by alias); 31 Mar 2003 17:58:37 -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 10303 invoked from network); 31 Mar 2003 17:58:37 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 31 Mar 2003 17:58:37 -0000 Received: from [128.164.132.31] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b2) with ESMTP-TLS id 3272877; Mon, 31 Mar 2003 12:58:20 -0500 Date: Mon, 31 Mar 2003 18:45:00 -0000 Subject: Re: review process Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Gerald Pfeifer , gcc@gcc.gnu.org, Fergus Henderson , Mark Mitchell , Gabriel Dos Reis To: Phil Edwards From: Daniel Berlin In-Reply-To: <20030331170450.GA15096@disaster.jaj.com> Message-Id: <63B6E972-63A2-11D7-96D3-000393575BCC@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg01810.txt.bz2 On Monday, March 31, 2003, at 12:04 PM, Phil Edwards wrote: > > Moving to gcc@. > Whoops, didn't notice it was somewhere else. :) > > 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). > I just wanted to make it explicit that i can't handle it otherwise. My current view is that this is a pretty simple SQL application (using a new database and the bug database), like so: 1. Any mail with [PATCH] in the title that we can see a well-formed patch in gets inserted into the new db (indexed by subject and message id) 2. Any mail approvals/denials for that message delete the [PATCH] record from the new db and update the bug (closing it), if one exists in the bug db. Since approvals/rejections can come at any time, we may or may not have created the bug report yet. 3. Every night, a cron job runs, and anything still in the database that is 1 day old and has no bug report created, gets one created. That should work, no? > >> 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., > That would work, if it's amenable to people. > 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