[Developers] Re: patch: CactusEinstein/IDAxiBrillBH cleanup

[Tom Goodale]

Hi Jonathon,

On Fri, 20 May 2005, Jonathan Thornburg wrote:

> Hi, Tom,
>
>> In general, small, specific patches will get quicker attention, and thus 
>> lower latency, than big patches which do lots of different things.  If 
>> you'd sent a note out to developers that you were doing this, and followed 
>> with a sequence of patches as you did things, it would have been easier.
>
> Well, actually I _did_ send a note out to developers about an early
> (partial) version of this set of changes.
>  http://www.cactuscode.org/pipermail/developers/2005-April/000822.html
>
> It wasn't a full-fledged "patch" then, because I didn't yet think I
> had a working version of IDAxiBrillBH.  (In hindsight I _did_ have a
> working version, the bugs I was seeing lay elsewhere.  But I didn't
> know that then...)
>
> The only reply I saw was from Erik,
>  http://www.cactuscode.org/pipermail/developers/2005-April/000823.html
> suggesting that I keep backwards compatability.  Inspired by his
> suggestion, I did so in my later changes.


Oops, sorry, I obviously missed that one, and didn't check back far enough 
in the archive.

> There is a larger problem, however:
>
>> although as you note at the bottom it
>> would be good if you could split the commits into smaller units, each
>> addressing an individual thing, e.g.
>> 
>>      relabeling latex
>>      adding comments to param.ccl
>>      adding the interpolator parameters
>>      adding new output (I agree that it should really be a GF so we can
>>                         use standard Cactus IO methods)
>>      add debugging stuff
>>      adding new stuff to the documentation
>>      etc
>
> Let's look for a moment at the process by which I could do this:
>
> 1. start with old version from CVS
> 2. discover and fix problem #1
> 3. create 'version 2 - version 1' patch, write description,
>   and send the whole thing to the appropriate mailing list
> 4. go on to discover and fix problem #2
> 5. oops, how do I create a 'version 4 - version 2' patch?
>   I don't have a copy of version #2 any more, and it's not in CVS
>   (because the 'version 2 - version 1' patch hasn't been approved yet)
>   Ok, so I need to check out a clean copy of the old version from CVS,
>   and roll it forward with the 'version 2 - version 1' patch.
>
> As you can see, this gets rapidly (maybe even quadratically) messier
> as one accumulates more and more changes.  By the time you get the
> dozen-plus changes incorporated in my current IDAxiBrillBH patch,
> it's just not practical.

I tend to agree, that's why I said it would have been good to have patches 
as time went on, rather than one big patch at the end.  Your original mail 
was about making more general interpolator stuff, however your final set 
of changes is much more extensive.  At this stage it is difficult to 
seperate them, but even now documentation changes could easily be split 
off.

> I admit that, had I known 6 weeks ago that I was going to make such
> extensive changes, I might have saved lots of intermediate versions.
> But I didn't.
>
> 	[In fact, it's even worse than that.
> 	Even if I had saved a 'version 2', a "version 4 - version 2'
> 	patch wouldn't apply cleanly after the 'version 2 - version 1'
> 	patch had been committed... because the $Header:$ lines
> 	in all the files will be different.]

I don't think that's insurmountable, and diff and patch are fairly good at 
things.  However if you submit patches as you go on, it is easier.

> So, to repeat the closing question from my patch message:
>
>> Apart from "switch to darcs", is there an elegant solution to this
>> problem?
>
> Should I create a private CVS branch for each code change that I
> think I might eventually want to submit as a formal patch?

I think that would probably be overkill, and I'd certainly not like to 
have branches except for really major changes where intermediate states 
may be completely unstable.  Lets see how we get on with more frequent, 
smaller patches and review if it turns out to be unworkable.  Note that 
even if you were committing immediately, without waiting for approval, I'd 
have asked for such a split-up, so it's not specifically an artifact of 
the patch-approve-commit cycle.

I agree that our current setup is far from ideal.  In the ideal case 
people would not be using the "development, unstable" version of the code 
for everyday work so I'd be less paranoid about it.  However with current 
resources it's proven impractical to have more frequent beta releases and 
thus to tell people to use the last released beta.

We will almost certainly move to a different version control system, or at 
the very minimum modify our use of CVS, in the future, but I keep hoping 
that we can release 4.0 final before doing a major shakeup of the 
infrastructure.  My current best estimate for that, though, is sometime in 
July.

On the subject of darcs, how have you found it in general, and have you 
had any problems with it on any architectures ?  How is its performance ?

Cheers,

Tom