From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10378 invoked by alias); 26 Oct 2005 12:57:18 -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 10344 invoked by uid 22791); 26 Oct 2005 12:57:15 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 26 Oct 2005 12:57:15 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EUkq8-0005V4-O9; Wed, 26 Oct 2005 08:57:12 -0400 Date: Wed, 26 Oct 2005 19:36:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: suggestion for future changes to GDB website Message-ID: <20051026125712.GA21126@nevyn.them.org> Mail-Followup-To: Joel Brobecker , Jim Blandy , gdb-patches@sources.redhat.com References: <20051025222234.GE900@adacore.com> <20051026002923.GC1155@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051026002923.GC1155@adacore.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00205.txt.bz2 On Tue, Oct 25, 2005 at 05:29:23PM -0700, Joel Brobecker wrote: > > Joel Brobecker writes: > > > I would like to suggest that we post changes to the htdocs CVS repository > > > to this mailing-list. That way, all developers have a chance to see and > > > react to changes. This does not necessarily mean that we should go > > > through the same formal process, with changelogs and all, but it would > > > be nice to see the patches, with a short explaination containing the > > > reason for the change if necessary. > > > > Do you mean posting the changes before they're committed, or after? > > I'm thinking after, but it's not a strong opinion. > > > If after, why not just set up an automatic patches list, as used for > > the source code? > > That's an option. The nice thing about posting the patch here is that > you can add an explaination to the patch. Revision histories are > sometimes a bit obscure... I'm strongly in favor of Joel's suggestion. -- Daniel Jacobowitz CodeSourcery, LLC