From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30771 invoked by alias); 20 Aug 2013 21:12:46 -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 30749 invoked by uid 89); 20 Aug 2013 21:12:46 -0000 X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 20 Aug 2013 21:12:45 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7KLCg3k023129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Aug 2013 17:12:43 -0400 Received: from barimba (ovpn-113-142.phx2.redhat.com [10.3.113.142]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r7KLCfci027005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 20 Aug 2013 17:12:42 -0400 From: Tom Tromey To: GDB Development Subject: A Proposal to Move to Git CC: Binutils Development Date: Tue, 20 Aug 2013 21:12:00 -0000 Message-ID: <8738q4gj7a.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-08/txt/msg00078.txt.bz2 I'd like to move gdb and binutils from CVS to Git. I've done much of the preliminary work and I will do the remainder, including the inevitable follow-up bug-fixing. I've read all the previous threads on the topic. I think I have internalized the big issues but it is possible that I am missing something. I'm sure you'll let me know. I think we should move specifically to git for two reasons. First, it is obviously better than CVS for the majority of work. Second, point #1 is borne out by observing that most active gdb developers are already using git. (I can't speak for binutils developers, though I do my rare binutils forays in git as well.) One principle I'm following in this proposal is to make the minimal change possible. That is, I want to focus on the conversion to git. Often times these discussions veer off into other process changes -- removing ChangeLogs, stuff like that -- but for this change we ought to concern ourselves solely with the rollout of git, and leave other changes for a later date. So, if you have other changes you want to propose, I would appreciate it if you would hold them until the transition is complete. Note that there are even some absurd cases of this I am leaving in-tree; for example the requirements, obsolete with git, to put a date into a branch name. 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; 2. You can already build just a subset of the tree; 3. This affects just the regular developers, not releases. I have been using http://sourceware.org/bugzilla/show_bug.cgi?id=14768 to track the to-do items. My understanding of the task list is: * Update the gdbadmin scripts. I've done this though I have not tested them. * Update the BFD daily date-updating commit. Not done. * Port log_accum_bugzillafied to git and set up git commit email. I've done this and tested the post-receive parts. * Update DJ's script that auto-merges some changes from GCC. Note that I think it will have to continue to merge to the 'src' CVS repository, for the benefit of projects left behind. Not done. * Examine gdb and binutils documentation to see what needs to be updated. This means looking at the texinfo manuals, the web sites, and the gdb wiki. I have patches for this. Once the infrastructure bits are in place, there is the matter of the conversion: * Convert the tree. We can perhaps reuse parts of the existing conversion process for this. I will try a test conversion at least once. Since the old history is available (see http://sourceware.org/ml/binutils/2012-10/msg00407.html), we can try to merge it before conversion. There seem to be several approach we can take here. I am investigating the options, but I'm interested in your expert advice. * Mark the various converted directories as read-only in CVS. This can be done via the commitinfo file. 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. Tom