From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7423 invoked by alias); 4 Jun 2006 21:08:06 -0000 Received: (qmail 7413 invoked by uid 22791); 4 Jun 2006 21:08:05 -0000 X-Spam-Check-By: sourceware.org Received: from rwcrmhc14.comcast.net (HELO rwcrmhc14.comcast.net) (204.127.192.84) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 04 Jun 2006 21:07:30 +0000 Received: from [192.168.0.101] (c-24-7-37-147.hsd1.ca.comcast.net[24.7.37.147]) by comcast.net (rwcrmhc14) with SMTP id <20060604210718m14007skd2e>; Sun, 4 Jun 2006 21:07:27 +0000 In-Reply-To: <87wtbw7iug.fsf@soliton.cs.tamu.edu> References: <4F2DF74A-5348-4D27-83A9-8F97110DA1B5@physics.uc.edu> <87lksde4h5.fsf@talisman.home> <571f6b510606040208m31e5e99bm80d0b8751e630ece@mail.gmail.com> <87irngllmn.fsf@talisman.home> <87wtbw7iug.fsf@soliton.cs.tamu.edu> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Richard Sandiford , Gerald Pfeifer , Steven Bosscher , GCC Mailing List Content-Transfer-Encoding: 7bit From: Andrew Pinski Subject: Re: Release Schedule issues and doubts Date: Sun, 04 Jun 2006 21:08:00 -0000 To: Gabriel Dos Reis X-Mailer: Apple Mail (2.746.3) X-IsSubscribed: yes 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 X-SW-Source: 2006-06/txt/msg00126.txt.bz2 On Jun 4, 2006, at 1:43 PM, Gabriel Dos Reis wrote: > > The trouble is there does not seem to be a clear gain in your > punishment system. At best it may just discourage people. > In a commercial organization, that might be a good system. For a free > project like GCC, it is not obvious where the long-term benefits for > the project are, given its "unconventional" way of "hiring" people. Which is why in my previous message, I proposed in giving rewards to ones which stick around and maintain. Do we want positive or negative reenforcement? > People get inactive for some period of time for various reasons, some > of whichg are not subject of public debate. My system said nothing about inactive people, only the active ones. The way I consider a person active maintainer is approving patches/ creating patches. If a person cannot follow up on the approval and/or creation, then why should we take the contribution if it causes problems? 2 months after the regression was found seems like a good time frame for figuring if the maintainer could handle the work load. Maybe we should have a time limit on how far after the patch went in, we should consider the regression significant to worry to give a punishment out. -- Pinski