From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9333 invoked by alias); 23 Nov 2004 21:52:53 -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 9323 invoked from network); 23 Nov 2004 21:52:48 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 23 Nov 2004 21:52:48 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id iANLx7Z5023780 for ; Tue, 23 Nov 2004 13:59:07 -0800 (PST) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Tue, 23 Nov 2004 13:52:47 -0800 Received: from [17.201.20.87] (mrs2.apple.com [17.201.20.87]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id iANLqjmd016961; Tue, 23 Nov 2004 13:52:46 -0800 (PST) In-Reply-To: <095801c4d180$19e95e40$f503030a@mimas> References: <200411230026.iAN0QqeO005220@sirius.codesourcery.com> <884E869E-56B9-43AD-ACDD-0F2A47287087@apple.com> <41A29C79.5070803@codesourcery.com> <20041123170139.GA4463@us.ibm.com> <095801c4d180$19e95e40$f503030a@mimas> Mime-Version: 1.0 (Apple Message framework v679) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: Janis Johnson , Mark Mitchell , gcc@gcc.gnu.org Content-Transfer-Encoding: 7bit From: Mike Stump Subject: Re: Mainline in regression-fix mode after Thanksgiving Date: Tue, 23 Nov 2004 22:14:00 -0000 To: Giovanni Bajo X-SW-Source: 2004-11/txt/msg00850.txt.bz2 I find the current thread kinda surreal. I would like to arguing in favor of setting a policy in which we automagically assign people the regressions they cause. One advantage, by exposing them to the after effects of what they do, with experience in such a system, they learn what types of changes cause what types of problems. I'll go so far as to say, most people actually change their behavior to match the automation. My experience is that this happens in 8-12 months. Having a machine do it, is easier to take, then having someone bring it up, if the machine brings up the issue, others, in time, generally won't have to. Our development model relies heavily on trust. I trust you will not make things worse, and you trust me, that I will not. Our users trust us that we won't put in regressions. Users are not unimportant. As to the question of important regressions v unimportant ones, things we plan on shipping broken, those can be xfailed/suspended/closed. The issue was raised that we can revert patches for regressions that are not promptly fixed. While this works some of the time, this breaks down when the regression is found via slow turn around testing (non-dejagnu testing), and sometimes these can take a year or more to show up, at that point, we generally can't just revert a change, as there may now be other work that relies in a more critical way, that the change is in. I don't think people need to unassign so others can take up the slack, I think people should just grab bugs they want to fix, and once fixed, close them. A bug that has been sitting for a year on someone's plate means that we need more maintainers in that area, or that the bug just isn't all that important. When people step forward to fix things, they are voting that the bug is important. I think that each person can decide if they work on a regression they caused or a bug they want to fix. In general, we want to encourage people to fix they regressions they cause. I think most people understand this. So, let me ask if anyone who puts in patches would object to having regressions assigned to them? If no one objects, I'd say, lets just make it policy.