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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user