Chris Shoemaker's (Jul) patch for account-*-balance refactoring and code

[Josh Sled]

On Sat, 2005-10-08 at 01:08 -0400, Chris Shoemaker wrote:

> Here's what happened: At some time long after sending those patches, I
> made more changes to Account.[ch].  Unless I go out of my way to make
> a new patch containing just the new changes, the new changes just get
> wrapped up into the same patch when the patch is refreshed.  Since the
> patch I sent hadn't been ack'd, nack'd, or commented on, I figured it
> would be ignored until I resubmitted, so I didn't make a new patch.

I'm a bit confused, here.  Why didn't you just cvs update the
patched-changes into your working copy and re-generate the new patch of
just the other changes?  Why is patch-generation 'out of [your] way'?


> Another solution would be to only apply patches "soon" after
> submission.  IOW, we'd agree that the patches expired after some time,
> and I would be free to change and resubmit after that time.
> 
> Any other suggestions or ideas?

Patches should be applied quickly; this was just a failing on our side.
I probably should have checked if you still "approved" the patch, given
that it was so old and I know you're making other changes.  (FTR, I did
ask about the INLINE_FUNC patch and haven't heard a reply yet... :)

I'm not sure what else can be done... there's an inevitable drift
problem as the patch ages and the tree changes independently.  I think
the only solution is to have less outstanding patches.  To me, this
means: smaller patches applied quickly, so your pool of outstanding
patches is small.


It doesn't sound like it's useful now that you've gone through and done
the work, but we can revert those changes if you want.

...jsled
-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`