Re: [RFA] Re: [RFC][patch 1/9] initial Python support

[Thiago Jung Bauermann <bauerman@br.ibm.com>]

On Tue, 2008-07-15 at 13:03 -0600, Tom Tromey wrote:
> >>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> 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