From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1456 invoked by alias); 31 Mar 2003 16:06:55 -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 1412 invoked from network); 31 Mar 2003 16:06:55 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 31 Mar 2003 16:06:55 -0000 Received: from [192.168.1.34] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b2) with ESMTP-TLS id 3272586; Mon, 31 Mar 2003 11:06:38 -0500 Date: Mon, 31 Mar 2003 17:50:00 -0000 Subject: Re: review process Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org, Fergus Henderson , Phil Edwards , Mark Mitchell , Gabriel Dos Reis To: Gerald Pfeifer From: Daniel Berlin In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg01803.txt.bz2 On Monday, March 31, 2003, at 02:46 AM, Gerald Pfeifer wrote: > [ gcc-patches -> gcc; please omit the former when replying! ] > > On Mon, 31 Mar 2003, Fergus Henderson wrote: >>>> - define a new category of "self-approve" developers? >> Well, the difference is that you're only allowed to approve your own >> patches, not someone else's patches. The intent here is to create >> a new position which is less trusted than a normal "maintainer", >> and whose approval powers are thus significantly limited -- >> limited to only approving their own patches, only after these patches >> have been reviewed by another human, and only after a one-week delay. > > So, wouldn't it be more natural, in some way, to have maintainers that > may approve all patches _but_ their own? (I'm not sure how well > reviews > by arbitrary third parties would work, both procedurally and related to > quality.) > > Managing droped patches using Bugzilla sounds like a good idea, and in > fact I have suggested it at least twice in the past. I can *almost* automate detecting missed patches after a day, too, since patch submission is generally in one of a small number of formats. It's actually detecting approval that is the tricky part right now. 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. 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. 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". > > My message at http://gcc.gnu.org/ml/gcc/2003-03/msg01529.html > essentially > has all three suggestions which came up in this thread, BTW. :-> > > Gerald > > -- > Gerald "Jerry" pfeifer@dbai.tuwien.ac.at > http://www.pfeifer.com/gerald/