From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2023 invoked by alias); 30 Aug 2013 23:37:05 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 2003 invoked by uid 89); 30 Aug 2013 23:37:04 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Aug 2013 23:37:04 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VFYFP-0007Li-Bg from joseph_myers@mentor.com ; Fri, 30 Aug 2013 16:36:59 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Aug 2013 16:36:59 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Sat, 31 Aug 2013 00:36:57 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VFYFL-0003J3-Sj; Fri, 30 Aug 2013 23:36:55 +0000 Date: Fri, 30 Aug 2013 23:37:00 -0000 From: "Joseph S. Myers" To: Hans-Peter Nilsson CC: Tom Tromey , GDB Development , Binutils Development Subject: Re: A Proposal to Move to Git In-Reply-To: Message-ID: References: <8738q4gj7a.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-08/txt/msg00134.txt.bz2 On Fri, 30 Aug 2013, Hans-Peter Nilsson wrote: > Sorry, but I have to react on that. I waited a bit, but I > really must say it: you say "all of us" like a the majority, but > I doubt that there are more of "all of you" than "all of us" > working on trees checked out as separate projects. Also, how is > that a change worth mentioning? *Your* work-flow isn't changed, > as you already check out gdb+binutils. I can accept the > inconvenience of the changed default thing that happens for "all > of us" remaining, and having to adjust my work-flow somewhat, > but I refuse to smile and call it good. For example, we'll now > each by default (when just going "make" after configure, not > "make all-foo all-bar all-baz" for the bits in our project) be > exposed to breakages in "the other" project, breakages unrelated > to "our own" project. Ok, now that I've got that out, over to > some more constructive comments. To build just one project, use --disable- options (this is already generically supported at toplevel). It would be useful for there to be documentation listing sets of such options to use for building particular subsets of projects. > At first I thought there was a huge inconvenience to projects > left in the cold with CVS, but it it's less huge, it seems they > will still be able to continue as they were - *except* they > won't be able to update the shared files like configure.ac. Rather, changing shared files now needs three repositories rather than two to change. If we can get agreement on GCC as the master, this could be automated as it is for libiberty (check into GCC and let the automatic process merge to the others). (Actually, my analysis suggests a master toplevel.git repository from which merges to all the others happen. But that's not required and can always be added later.) > local "src" tree? Ok, now that you read and disliked that, how > about the obvious alternative; offering to add them later to the > binutils+gdb git? Then I think it would be preferred to *not* > name the git repo "the gdb+binutils repo", but (ehhh...) the src > repo! No, I think it should be binutils+gdb and other projects should not be added to it. Most of the problems with the combined repository have been because it combines logically unrelated projects. A key goal as I see it is that checkouts, updates, branching, tagging etc. work in the ordinary way for the version control system being used, without any further special steps or oddities - the existing use of CVS modules fails that ("cvs update -d" checks out things that aren't wanted in your partial checkouts) and so do things such as git submodules - which indicates avoiding such things in git arrangements. Given how BFD is an integral part of both binutils and GDB, a binutils+gdb repository seems to be the smallest convenient unit. > To summarize the actions I want: > - Git migrations and work-flow offered for remaining projects > (like newlib and cgen). By design, it's for each project to choose to migrate or not, to its own repository, independently, including choosing whether git is the version control system they want at all. As I noted in , cgen doesn't appear to use the shared toplevel at all, so if it moves out of src, it would just be the cgen directory moving without a copy of anything at toplevel; with regard to binutils+gdb, it's just another build tool. If all active projects move out, we really ought then to try to sort out the Unix groups on sourceware (replace the "src" group by putting the people writing to each project in a group for that project which controls access to just the relevant repository - so a binutils+gdb group, a newlib group, etc.). -- Joseph S. Myers joseph@codesourcery.com