From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15322 invoked by alias); 30 Aug 2013 22:58:44 -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 15301 invoked by uid 89); 30 Aug 2013 22:58:43 -0000 Received: from arjuna.pair.com (HELO arjuna.pair.com) (209.68.5.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Fri, 30 Aug 2013 22:58:43 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00,KHOP_THREADED autolearn=ham version=3.3.2 X-HELO: arjuna.pair.com Received: (qmail 95461 invoked by uid 3006); 30 Aug 2013 22:58:40 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Aug 2013 22:58:40 -0000 Date: Fri, 30 Aug 2013 22:58:00 -0000 From: Hans-Peter Nilsson To: Tom Tromey cc: GDB Development , Binutils Development Subject: Re: A Proposal to Move to Git In-Reply-To: <8738q4gj7a.fsf@fleche.redhat.com> Message-ID: References: <8738q4gj7a.fsf@fleche.redhat.com> User-Agent: Alpine 2.02 (BSF 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2013-08/txt/msg00133.txt.bz2 First and foremost, thanks for setting this in motion. On Tue, 20 Aug 2013, Tom Tromey wrote: > The basics of the plan are as outlined by Joseph Myers: > > http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html > > For the purposes of this discussion I think you can focus on 6.b -- a > shared gdb+binutils repository. > > The reason for a shared repository is simply that binutils and gdb > share a substantial amount of code, mainly BFD, but other things as > well. > > This gives the change minimal impact. It is not zero impact, but: > > 1. It is superior for all of us to build the whole tree, to avoid > those (rare) occasions where BFD changes break other parts of the > build; 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. The work-flow changes for those of us that *want* to still build with separate trees (like, with auto-testers) should be written down and supported, not just implied and left on our own. I see changes to the src-release scripts, so let's make that the number one supported way of generating a separate tree: through intermediate release-like tar-balls. (No, not git sparse checkouts. Too many local steps that *will change as projects add files*, and also needing something like git-1.7.10 to be bug-free.) But, lots of modules are unnamed in src-release, for example the "sim" module. Let's add those in CVSROOT/modules that are missing from src-release but are still maintained in the src tree (e.g. excluding dejagnu) as part of a migrated project. I see a couple of strange ones in the src-release script that are not in CVSROOT/modules (like separate gas and gas+binutils - without ld or gprof), so a pristine-ness-argument can't be used as a counter-argument, please, thank you. :) 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. That's a bit more than inconvenient. Thus, there should be a migration path offered as part of this effort and it's not someone elses issue. I guess someone will dislike the following suggestion, but how about separate per-directory repos, using git submodule, with steps explaining how to add them to your 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! To summarize the actions I want: - Git migrations and work-flow offered for remaining projects (like newlib and cgen). - (related:) Do not set in stone this git repo as "binutils+gdb" in any documentation changes and names. - Add remaining "partial checkout" methods as mentioned in modules to src-release, for related migrating projects (well, at least "sim"). Mention this as a (the only?) supported way to generate the project-specific tree. I'll add them to PR14768 and hope to make the src-release changes unless beaten to it. > I'd like to do the final switch around mid-September. Not sooner, > because I am going to be away for a little while near the end of > August, and I want to be available to fix problems. Very much appreciated. brgds, H-P