From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25620 invoked by alias); 16 Jul 2008 07:14:13 -0000 Received: (qmail 25562 invoked by uid 22791); 16 Jul 2008 07:14:11 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 Jul 2008 07:13:50 +0000 Received: from mailhub3.br.ibm.com (unknown [9.18.232.110]) by igw3.br.ibm.com (Postfix) with ESMTP id 787C039000D for ; Wed, 16 Jul 2008 03:55:36 -0300 (BRST) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m6G7Djid1773766 for ; Wed, 16 Jul 2008 04:13:45 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6G7DeIS002247 for ; Wed, 16 Jul 2008 04:13:40 -0300 Received: from [9.18.202.6] ([9.18.202.6]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6G7De5K002141; Wed, 16 Jul 2008 04:13:40 -0300 Subject: Re: [RFA] Re: [RFC][patch 1/9] initial Python support From: Thiago Jung Bauermann To: Tom Tromey Cc: gdb-patches ml In-Reply-To: References: <20080429155212.444237503@br.ibm.com> <20080429155304.288626880@br.ibm.com> <20080528205921.GA2969@caradoc.them.org> <20080615181833.uxmo25mg0kko40kw@imap.linux.ibm.com> <1216107418.14956.27.camel@localhost.localdomain> <1216146743.14956.56.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 16 Jul 2008 07:14:00 -0000 Message-Id: <1216192405.14956.76.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00334.txt.bz2 On Tue, 2008-07-15 at 13:03 -0600, Tom Tromey wrote: > >>>>> "Thiago" == Thiago Jung Bauermann writes: > Thiago> Well, my suggestion is to stop using the git repo and move > Thiago> everything here to the mailing list. After the 1st (initial > Thiago> python support) and 2nd (export values) patches are accepted > Thiago> (and they seem to be close), I don't see a reason to keep > Thiago> working in a separate branch. But if you prefer to continue to > Thiago> use it, we can think of improvements to the process (like > Thiago> rebasing to a clean CVS HEAD, for instance). > > I'm a bit reluctant to move purely to working from CVS. This will > make it harder for us to work on things in concert, and will require a > lot of administrative overhead as well. One thing that has been nice > about this project, so far, is that we can be fairly experimental and > we don't have to spend much time waiting... whereas my > cvs-head-hacking experience has been pretty much the opposite. Ok, makes sense. We can keep working in the branch. > Thiago> sure if they are ready to be approved) send you a patches/ > Thiago> directory suitable for use with quilt, and from there each of > Thiago> us drive his own patches to acceptance (there are one or two > Thiago> which have both our names in the changelog. We can have a duel > Thiago> at sunset to decide about those). > > What if we used 'guilt' or 'StGIT' instead? I have never tried these, > but they both seem to basically be git+quilt, where the patches can > easily be shared. (Am I wrong about this?) I never used any of those, but from the cursory reading I just had about them, it seems you are wrong about the "patches can easily be shared" part. These tools seem designed to keep a private set of patches updated against some remote branch, not intended to push and pull patches around. > This would require anyone working on the git repository to use this > tool and to be careful about managing the patches. But, that would > take the work off you and spread it around -- exactly what we want. Well, I think we can make some small improvements to the current process so that the work of keeping the patches should be lighter: I just updated the patches-base branch to a pristine CVS HEAD from today (by the way, the git repo was almost pristine already, the problem I had was with some change from upstream. My bad.), and I rebased the python-patches branch against it. So the patches are all refreshed to today's HEAD. I also resolved some minor differences between the code in the python-patches and python-revisited branches, which inflicted some unnecessary merge conflicts. These must have crept in while I was initially dividing the code in patches. The python-patches and the python-revisited trees are now exactly equal (as they should have always been). I didn't push the latter yet because there's a build problem that I need to sort out... And to keep things that way, my idea is to update the patches-base branch from time to time (every two weeks? one month?) and merge it into python-revisited. I think this will bring down the number of conflicts, which is the biggest time sink here. (Also keeping the commits focused helps a lot since then there's rarely the need to break the commit in two or three parts, but we've been doing that already). -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center