From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20349 invoked by alias); 10 Mar 2003 00:07:39 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20328 invoked from network); 10 Mar 2003 00:07:38 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by 172.16.49.205 with SMTP; 10 Mar 2003 00:07:38 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h2A07bnR002256 for ; Sun, 9 Mar 2003 16:07:37 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Sun, 9 Mar 2003 16:07:33 -0800 Received: from apple.com (moleja.apple.com [17.201.22.21]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id h2A07bs26798 for ; Sun, 9 Mar 2003 16:07:37 -0800 (PST) Date: Mon, 10 Mar 2003 00:07:00 -0000 Subject: Re: [bangerth@ticam.utexas.edu: GCC review process: how to handle external submissions] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Jason Molenda To: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit In-Reply-To: <20030308202134.GB32507@redhat.com> Message-Id: <128422FC-528C-11D7-A114-003065BC3540@apple.com> X-SW-Source: 2003-03/txt/msg00144.txt.bz2 > From: Wolfgang Bangerth > To: gcc@gcc.gnu.org > Subject: GCC review process: how to handle external submissions > Date: Sat, 8 Mar 2003 00:40:09 -0600 (CST) > > > I think we have a serious problem here. We are not only losing the > contributions from these people, we are also scaring them away, and I > don't think this is wise. > > Can we at least discuss the reasons for this, and maybe come up with > suggestions about how we could improve this process? I think it would > be > tremendously helpful if there were someone who And to further demonstrate that we're all discussing the same problem at the same time, this came up on the subversion-dev list last week. Their approach is to have humans do it by hand. cf http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=32389 It's an interesting approach -- it takes advantage of the idea that there are many volunteers interested in helping a project but aren't hacker gods. On the other hand, it assumes that the volunteer won't disappear or let things drop on the floor if he runs short on time... J