From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3143 invoked by alias); 20 Feb 2004 00:34:07 -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 3134 invoked from network); 20 Feb 2004 00:34:06 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 20 Feb 2004 00:34:06 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8B9682B92; Thu, 19 Feb 2004 19:34:02 -0500 (EST) Message-ID: <403555FA.2030003@gnu.org> Date: Fri, 20 Feb 2004 00:34:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: GDB 6.1 branch 2004-02-26-gmt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00268.txt.bz2 Hello, It's time has come. Things appear to have died down, and the backlog sufficiently drained, for the GDB 6.1 branch to be cut. With about a week's notice I'm planning on: -D 2004-02-26-gmt as the branch date. If things go to plan, that makes the ideal release date: -D 2004-04-14-gmt (6 weeks) So can I suggest treating the next week as something of a quiet period (....). Right now the bug database shows: 378 ``GNU/Linux'' ``Linux kernel'' as the only high/build PR (that can't be right). enjoy, Andrew PS: Branch Commit Policy The branch commit policy is pretty slack. @itemize @bullet @item The @file{gdb/MAINTAINERS} file still holds. @item Don't fix something on the branch unless/until it is also fixed in the trunk. If this isn't possible, mentioning it in the @file{gdb/PROBLEMS} file is better than committing a hack. @item When considering a patch for the branch, suggested criteria include: Does it fix a build? Does it fix the sequence @kbd{break main; run} when debugging a static binary? @item The further a change is from the core of @value{GDBN}, the less likely the change will worry anyone (e.g., target, architecture, or system specific code). @item Only post a proposal to change the core of @value{GDBN} after you've sent individual bribes to all the people listed in the @file{MAINTAINERS} file @t{;-)} @item Only the very brave or very foolish would try to apply the obvious fix rule to the branch. @end itemize @emph{Pragmatics: Provided updates are restricted to non-core functionality there is little chance that a broken change will be fatal. This means that changes such as adding a new architectures or (within reason) support for a new host are considered acceptable.}