From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27247 invoked by alias); 19 Feb 2003 17:33:40 -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 27234 invoked from network); 19 Feb 2003 17:33:40 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 19 Feb 2003 17:33:40 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h1JHXVo27474; Wed, 19 Feb 2003 09:33:31 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: Daniel Jacobowitz , Jim Blandy , gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process References: <20030217180709.GA19866@nevyn.them.org> <20030218042847.50F2E3CE5@localhost.redhat.com> <20030217180709.GA19866@nevyn.them.org> <20030218023553.2BBB73D02@localhost.redhat.com> <20030217180709.GA19866@nevyn.them.org> <15953.20132.193102.752916@localhost.redhat.com> <20030219014904.GA11446@nevyn.them.org> <3E539ABA.4050203@redhat.com> From: David Carlton Date: Wed, 19 Feb 2003 17:33:00 -0000 In-Reply-To: <3E539ABA.4050203@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00359.txt.bz2 On Wed, 19 Feb 2003 09:54:50 -0500, Andrew Cagney said: > One thing GCC(4) and GDB are now is encouraging exprementation on > branches development to always occure on branches cut from the the > relevant repository. Would Red Hat be happy hosting significant branches for other companies? Would those other companies be happy depending on Red Hat's CVS servers? (Maybe a reasonable answer here is "yes, but money should change hands".) It might be nice if GDB were using a source code management tool that didn't depend on having a single repository, making it easier for people to maintain public branches elsewhere but to still sync them with an official branch. Anyways, I'd been planning for a while to write up some documentation about creating branches; I'll try to do that sooner than later. I was somewhat resistant to the idea myself, but in retrospect it was unquestionably the right way to go for my project. David Carlton carlton@math.stanford.edu