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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Josh Sled-2
Log Message:
-----------
Chris Shoemaker's (Jul) patch for account-*-balance refactoring and code format/comment massage.
2005-10-07  Joshua Sled  <[hidden email]>

        Patch from Chris Shoemaker <[hidden email]>:
        * src/engine/Account.[ch]: Refactoring of
        account-*-balance(as-of-date) code.
        * src/engine/Account.[ch], src/engine/Group.[ch]:
        Tyop/misspelling correction, formatting cleanup, notes and
        comments.

Tags:
----
gnucash-gnome2-dev

Modified Files:
--------------
    gnucash:
        ChangeLog
    gnucash/src/engine:
        Account.c
        Account.h
        Group.c
        Group.h
_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
Reply | Threaded
Open this post in threaded view
|

Re: 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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-patches

_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
Reply | Threaded
Open this post in threaded view
|

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

Josh Sled
In reply to this post by Chris Shoemaker
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}`
_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
On Sat, Oct 08, 2005 at 10:07:36AM -0400, Josh Sled wrote:

> 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'?
>

Hmm. I wish I'd thought of that.  That probably would've been the
easiest way.  Just to explain: The reason I didn't think about it is
that it's kind of orthogonal to my normal workflow.  I never keep
patched trees around, just the bare patches.  Normally, there are
never any changes in my tree when I do a cvs update, so there are
never any conflicts.  Here's why: If there are any applied patches
during the update then quilt will mistakenly think that the updates
that came from cvs should be in the refreshed patch.  So, I have to
pop the entire patch stack, cvs update, and then re-apply my patch
stack, resolving conflicts as I go.

In the future, I think I'd resolve this type of problem post-facto by:
checkout cvs versions from before the apply, manually apply my patch,
do a cvs update, and cvs diff to get a new patch.  Quite simple,
really, just completely different from my normal workflow.  Thanks for
pointing that out.

>
> > 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... :)

Sorry, I missed (or forgot?) that, I'll go look it up and respond.

>
> 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.
>

Agreed.  I'd love to reduce the size of my patch stack.

>
> 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.
>

No need.

-chris

> ...jsled
> --
> http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-patches mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches