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

[Didier Vidal]

Bugzilla might be a good tool to save this kind of follow-up problems.
We could either:

* Use it only for large patches:
  - submit the patch to gnucash bugzilla
  - post an email to gnucash-patches with a link to the bugzilla entry,
and info such as 'This patch has a consistent set of features. I plan to
continue working on it to refine them. Add followup info on bugzilla if
you are working on its integration in the cvs tree, or if you see issues
with the feature or its implementation. Please, check the buzilla entry
before commiting it, in case I have issued a patch cancelation'

* Or use it for every patch submition.
  - entry in gnucash mozilla + notification to this mailing list
  - maintainers with cvs commit access would modify the bugzilla ticket
if they are working on the patch, and close the ticket after commit or
rejection.

Didier.

> On Fri, Oct 07, 2005 at 06:40:43PM -0400, Joshua Sled wrote:
> > Log Message:
> > -----------
> > Chris Shoemaker's (Jul) patch for account-*-balance refactoring and code format/comment massage.
> 
> 
> :( 
> 
> Ok, I'm pretty keen on never again having to do what I just spent this
> evening doing.  I know this was mostly my own fault (not Josh's), but
> I want to choose the most convenient way of preventing it from
> happening again, which depends on you other devs.
> 
> 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.
> 
> When Josh did apply the patch, it was, of course, the version from
> July, the only version I ever mailed.  Unfortunately, this left me
> with a large patch containing *mostly* stuff just applied.  Filtering
> out that remaining new stuff turned out to be more painful than one
> might think.
> 
> So how can I prevent this?  One solution would be for me to not ever
> change patches after I mail them.  The disadvantage of this is that
> sometimes multiple changes group naturally and/or logically into one
> patch.  Also, it does raise the ambiguity of patch ordering: I can't
> know in which order the patches will be applied, so I guess I must
> pick an order and note the dependence.  It's also a little more work.
> 
> Another solution would be for anyone to check with me for a newer
> version if they're applying an old patch.  That would probably save
> work for everybody, since I have to keep my patch stack fresh anyway
> in order to code.
> 
> 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?
> 
> -chris
> 
> p.s. All things considered, things could have been *much* worse.  If
> I'd sent more than just the small sample of patches, I could've been
> sorting for a week instead of just an evening.  But, I do want to send
> a much larger batch of patches pretty soon, so let's settle on
> something that won't incapacitate me.
> _______________________________________________
> gnucash-patches mailing list
> gnucash-patches at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-patches