Re: gEDA-user: rant: pcb print from command line

[Kai-Martin Knaak <kmk@xxxxxxxxxxxxxxx>]

On Mon, 08 Mar 2010 21:30:39 +0000, Peter Clifton wrote:

> Some developers - like (sorry to say, I'm speaking purely for myself
> here), are damned right lazy, and sometimes need a little cajoling to
> get things done. 

Well, that's why I brought up the subject twice on this list.


> Getting patches merged is sometimes about reminding people, and making
> things _easy_ for them.. 

Fair enough. 

Providing easy to merge patches would be easier if there were a HOWTO in
the docs. This should be a fool proof and detailed step-by-step. Much
more detailed than 
	http://pcb.gpleda.org/bugs.html
or 
	http://geda.seul.org/wiki/geda:faq-gschem?s=bug#i_found_a_bug_what_can_i_do_about_it


> I'm about 90% more likely to look at something if someone provides me a
> click-able link,

Please provide a recipe that tells me what format the link, the patch ,
or whatever should be and how to produce it. I'd gladly apply the 
recipe and I am sure, others will, too.


> KMK, I've found the patch you're referring to in my email client, but it
> makes me nervous to apply it directly. Touching hidnogui.c to remove the
> CRASH; statement - why is that needed?

Honestly, I don't really know. For some reason nogui_invalidate_lr is 
called, whenever an action is executed while there is no GUI active. 
There is no description what hidnogui.c is supposed to do in the first 
place -- No explicit comment on the meaning of "lr" in the name of the
procedure, either.

Just in case you haven't already recovered it from the mail archive. 
Ineiev reviewed the patch and suggested a modified patch, that 
removes the variable Setttings.init_done:
http://archives.seul.org/geda/user/Oct-2009/msg00338.html


> The patch isn't from a local "git
> commit", so doesn't have a log entry explaining what it does.

Again, give me a step-by-step recipe on how to obtain a convenient patch
and I'll gladly follow.

 
> As a developer "applying" your patch, I would have to figure that out,
> and write one (possibly incorrect), or I'd have to come back and query
> you for it. By applying the patch, I'm effectively vouching for it, and
> that is difficult to do without testing.

You mean, I should provide a test case 


> (Remember that I'm lazy... hacking on my own pet
> project stuff has a much lower entry level!)

Remember, that us non-developers are just clueless. We need explicit
advice on how to provide patches. How about a patch-submit-checklist 
in the wiki?


> "
> Grep couldn't didn't find this function anywhere else in the source. So
> I am a bit clueless where this error message is triggered. As a
> workaround I simply commented the corresponding CRASH line in hidnogui.c
> "
> 
> The "workaround" worries me.

Me too. I understand why you hesitate to apply the patch right away. 
However, this should not postpone the bug fix infinitely, but trigger
a clarification, what hidnogui.c is actually meant for. Like I said,
in the commit, I am pretty much clueless on how a procedure can be 
called if it is nowhere else to be found in the source. 
 

> FWIW, gdb ought to show you what is happening

Cough, gdb -- It must have been 11 years since I last wrestled with 
that beast. I vaguely remember to have used a front-end called ddd.
Is this still the tool of choice?


> At most, you might put,
> 
> /* NB: This function is a NOP. We don't call CRASH; as in other hidnogui
>  *     functions, since this function can be called when exporting from
>  *     a command line specified aciton script. */
> 
> Much more verbose, but very clear to anyone than just wondering why /*
> CRASH; */ is commented out.

ok, fair enough. 


> On the other hand, I am reluctant to bash down people's patch
> contributions with continual bombardment to polish them endlessly.
> Falling back to the "I'm busy" stance is lots less confrontational than
> me batting the patch back to you and demanding revisions before I apply
> it.

"I am busy" may seem more polite. However, it makes me want to me go 
away and invest my not so many free cycles elsewhere. In fact, the 
main reason why I still insist to contribute is me being locked-in to 
geda/pcb ;-) 

 
> Perhaps we should just apply the patch as is, and catch any bugs (if)
> they appear. 

On the positive side, it adds substantially to the power of pcb. 
Scriptable, yet customized printing is essential for a smooth 
work flow in an environment with many small projects. 


> I don't want to discourage future contributions.

:-)

---<(kaimartin)>---
-- 
Kai-Martin Knaak
Ãffentlicher PGP-SchlÃssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53



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