Re: gEDA-user: Information on PCB

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Wed, 2009-10-21 at 20:09 +0100, Peter Clifton wrote:
> On Wed, 2009-10-21 at 10:08 -0700, Jared Casper wrote:
> 
> > Sure, but it takes at least a bit more effort to make a patch ready to
> > submit to the project (make the code more general purpose as opposed
> > to a quick hack, clean up the code, test with other hid's/workflows,
> 
> Yep... that's why the PCB+GL code, and all the polygon speedup stuff
> sitting underneath it is still in my private repository ;)

[snip]

> Keep writing good patches, and you'll find yourself with git commit
> access soon enough.. then you will not have to worry about the lost
> patch problem - just the QA issues you identified above.
> 
> I'm stuck in QA hell with the PCB+GL stuff at the moment ;)

Oh.. and for what its worth.. it is hard enough understanding, checking
and reviewing _my own_ patches.. let along someone else's!

The more complex / messy the code the patch deals with (and lets face
it, PCB has a lot of messy and / or complicated code), the harder it is
to be sure that a given patch is "right".

I'm now in a situation where I'm looking at patches like

Patches: A + B + C + D == working solution

But each patch along the way also introduces / removes a lot of debug
comments, #if 0 sections, debug printf's etc..

I could just squash the patch down to one delta - but then I loose the
details of how it was constructed, along with some review-ability.

The frustrating truth is.. that of the 30+ complex patches in my stack,
when I go to commit one (or merge it down with some other), I typically
generate more patches. 3 of the commits I just pushed came from just one
in my stack!

Best wishes,



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user