From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17886 invoked by alias); 7 Mar 2002 02:14:48 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17811 invoked from network); 7 Mar 2002 02:14:46 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 7 Mar 2002 02:14:46 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id AD3763D1D for ; Wed, 6 Mar 2002 21:14:45 -0500 (EST) Message-ID: <3C86CD15.6070401@cygnus.com> Date: Wed, 06 Mar 2002 18:14:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: ["patch"/rfa/doc] Doco branch commit policy Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00089.txt.bz2 Another section (this is part of the releasing GDB chapter). Thoughts? Andrew @section Branch commit policy The branch commit policy is pretty slack. @value{GDBN} releases 5.0, 5.1 and 5.2 all used the below. @itemize @bullet @item the @file{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 then mentioning it in the @file{gdb/PROBLEMS} file is better than committing a hack @item try approval criteria like: does it fix a build; does it fix the sequence @kbd{break main; run} on a static binary @item the further a change is from the core of @value{GDBN} the less likely the change will worry anyone (i.e. target 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 :-) @end itemize @emph{Pragmatics: Provided update 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 new architectures or (within reason) support for a new host are considered acceptable.}