Re: gEDA-user: rant: pcb print from command line
> I'm very bad at following stuff in the sourceforge trackers, partly > since I _HATE_ the sourceforge site with a fiery passion. Why not just move to LaunchPad? If it is set up and all the docs point in that direction then all new bugs/issues will be added there. The SF bugs just need to be worked through slowly until they are all closed (moving them is a waste of energy). Is there some particular developer resistance to LaunchPad? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Thursday 11 March 2010 13:55:29 Peter Clifton wrote: > On Wed, 2010-03-10 at 20:52 +, Peter TB Brett wrote: > > We (Peter C & I) try quite hard to keep on top of patches to > > gschem/libgeda etc., y'know. Putting them in the tracker makes things a > > lot easier for us, and I really encourage you to keep doing that. > > I'm very bad at following stuff in the sourceforge trackers, partly > since I _HATE_ the sourceforge site with a fiery passion. Well, yeah, you're not the only one. ;-) Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Wed, 2010-03-10 at 20:52 +, Peter TB Brett wrote: > We (Peter C & I) try quite hard to keep on top of patches to gschem/libgeda > etc., y'know. Putting them in the tracker makes things a lot easier for us, > and I really encourage you to keep doing that. I'm very bad at following stuff in the sourceforge trackers, partly since I _HATE_ the sourceforge site with a fiery passion. I do try to keep an eye on new stuff which appears on the geda-bug mailing list though. (Which is where the geda bugmail goes). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Tue, 09 Mar 2010 21:11:08 -0500, Bob Paddock wrote: >> fwiw, there is a pcb-bugs mailing list with only me as the subscriber. >> Of course in all fairness, that list didn't exist yesterday ;) That >> list will get all new bug reports and updates to existing reports. > > Don't see it listed at any of these seemingly likely places: > > http://www.gpleda.org/mailinglists.html > http://pcb.gpleda.org/bugs.html If these pages were part of the wiki, no valuable developer time would be needed to keep them up to date. ---<(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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Wed, Mar 10, 2010 at 12:52 PM, Peter TB Brett wrote: > We (Peter C & I) try quite hard to keep on top of patches to gschem/libgeda > etc., y'know. Putting them in the tracker makes things a lot easier for us, > and I really encourage you to keep doing that. > Sorry, didn't mean to diminish your efforts, I appreciate it. As shown by the g-code patch, it does work on occasion. Just pointing out that as is putting a patch on sourceforge is no guarantee it will be seen. (the "... go to die" quote was quoting Peter C). Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Wednesday 10 March 2010 20:26:41 Jared Casper wrote: > On Wed, Mar 10, 2010 at 12:18 PM, Alberto Maccioni > > wrote: > > This: > > http://sourceforge.net/tracker/?group_id=73743&atid=538813 > > > > which is also linked from: > > http://www.gpleda.org/developer.html > > Ah yes... unfortunately, at present, "Sourceforge is where patches go > to die"*. I've had more success getting patches applied by emailing > them to this list then posting them there, even though that is the > preferred method according to the website. Hopefully that'll change > and eventually a standard, actually used, procedure for community > contributions will arise out of all of this (be it sourceforge or > not). > We (Peter C & I) try quite hard to keep on top of patches to gschem/libgeda etc., y'know. Putting them in the tracker makes things a lot easier for us, and I really encourage you to keep doing that. Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Wed, Mar 10, 2010 at 12:18 PM, Alberto Maccioni wrote: > This: > http://sourceforge.net/tracker/?group_id=73743&atid=538813 > > which is also linked from: > http://www.gpleda.org/developer.html > Ah yes... unfortunately, at present, "Sourceforge is where patches go to die"*. I've had more success getting patches applied by emailing them to this list then posting them there, even though that is the preferred method according to the website. Hopefully that'll change and eventually a standard, actually used, procedure for community contributions will arise out of all of this (be it sourceforge or not). Jared *http://archives.seul.org/geda/user/Oct-2009/msg00258.html ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
This: http://sourceforge.net/tracker/?group_id=73743&atid=538813 which is also linked from: http://www.gpleda.org/developer.html 2010/3/10 Ethan Swint : > Yes - but what is the function!?! (A,B,C; 1,2,3 please.) > > On 03/10/2010 03:07 PM, Alberto Maccioni wrote: >> >> I called it a procedure, but it's the fact that there is a submit >> patch function; it's so obvious to any developer that it's not written >> anywhere. >> And I didn't notice it until very recently. >> >> >> 2010/3/10 Jared Casper: >> >>> >>> On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni >>> wrote: >>> the code on the mailing list, but it took me several months to discover the "submit patch" procedure. >>> >>> What procedure did you find? >>> >>> Jared >>> >>> >>> ___ >>> geda-user mailing list >>> geda-user@moria.seul.org >>> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >>> >>> >> >> ___ >> geda-user mailing list >> geda-user@moria.seul.org >> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >> >> > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
Yes - but what is the function!?! (A,B,C; 1,2,3 please.) On 03/10/2010 03:07 PM, Alberto Maccioni wrote: I called it a procedure, but it's the fact that there is a submit patch function; it's so obvious to any developer that it's not written anywhere. And I didn't notice it until very recently. 2010/3/10 Jared Casper: On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni wrote: the code on the mailing list, but it took me several months to discover the "submit patch" procedure. What procedure did you find? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
I called it a procedure, but it's the fact that there is a submit patch function; it's so obvious to any developer that it's not written anywhere. And I didn't notice it until very recently. 2010/3/10 Jared Casper : > On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni > wrote: >> the code on the mailing list, but it took me several months to >> discover the "submit patch" procedure. > > What procedure did you find? > > Jared > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni wrote: > the code on the mailing list, but it took me several months to > discover the "submit patch" procedure. What procedure did you find? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Tue, Mar 9, 2010 at 5:06 PM, Dan McMahill wrote: > Here's an example of a place where extra help wouldn't have needed any > knowledge of internals. Over the years there have been various bug reports > about some of the footprints that ship with pcb. For each of those, the > process becomes > Since footprint bugs take so long, maybe some triage is necessary. I think it make sense for you developers to make a footprint category, plop all of these in there and concentrate on pruning the list of bugs that require a developer to handle. (I agree with the idea that has been posted here before that a symbol/footprint/model/etc. library for gEDA should be a separate project altogether) I think it would help to organize the bugs in there. Currently there are 140 open bugs, most without a category, no groups used, and all priority 5. I can imagine for a developer it just looks like a mountain of sludge that would take a lunch break just to start on something. The tracker would probably be more useful and thus used more if it were more manageable. Well defined categories, groups and priorities would go a long way. Given access I'll try to make some time start trudging through and cleaning the trackers up, but can't do much myself as is. > Another example is when a new HID is added. Almost no existing code is > touched. However, it needs to be built. Code needs to be checked for > formatting (run through indent(3)), compiler warnings checked, basic Does PCB and/or gEDA have a coding style preference, let alone one documented somewhere? > author didn't provide that, etc. I spent probably 2 hours today (my entire > lunch and a chunk of my evening) on a single patch submission to get it to > where I didn't feel bad about it. At this rate, it would take me a month of And now PCB has a gcode exporter. Sweet! :) > full time work to get through the bug and patch database I went ahead > and did it on this one, but in general, it would have been useful to have > extra hands to do some of these checks and to help out the author (whose > work I really appreciate, this email is not meant to complain since he put > in a lot of work already). > ... so for the patches that you can't put so much time into, just a comment to say what needs to be done before it gets applied would go a long way. The submitter has most likely spent enough time on the patch that they probably won't mind spending another hour or two doing the necessary grunt work to get it included in the main repository. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
I totally agree with you (as a new user interested in developing). 2010/3/10 Alberto Maccioni <[1]alberto.macci...@gmail.com> I submitted a patch for PCB about a month ago and it has been reviewed these days; is this too much delay? Probably not, but now I read that including tests would have made the reviewing job easier and possibly shorter. But I didn't even know of the existence of such tests: the point is that to the non-developers nothing is obvious; I had already posted the code on the mailing list, but it took me several months to discover the "submit patch" procedure. If only there was a quick tutorial on how to do these kind of operations I think the number of developers (or at least reviewers) would grow substantially. Do you lose time because people don't post links? Well, write it down so people will know how to correctly report a bug. Also some very basic document about the internal structure of PCB is needed; think about what it takes for a novice to locate the code that he needs to change; without advice he will probably desist, and that is a potential developer lost. No wonder there are only a handful of active developers. I know that writing documentation is not fun and takes time, but for a project of this complexity it is critical to attract more people, and I think in the long run it has even a better return than coding. Alberto ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:alberto.macci...@gmail.com 2. mailto:geda-user@moria.seul.org 3. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
I submitted a patch for PCB about a month ago and it has been reviewed these days; is this too much delay? Probably not, but now I read that including tests would have made the reviewing job easier and possibly shorter. But I didn't even know of the existence of such tests: the point is that to the non-developers nothing is obvious; I had already posted the code on the mailing list, but it took me several months to discover the "submit patch" procedure. If only there was a quick tutorial on how to do these kind of operations I think the number of developers (or at least reviewers) would grow substantially. Do you lose time because people don't post links? Well, write it down so people will know how to correctly report a bug. Also some very basic document about the internal structure of PCB is needed; think about what it takes for a novice to locate the code that he needs to change; without advice he will probably desist, and that is a potential developer lost. No wonder there are only a handful of active developers. I know that writing documentation is not fun and takes time, but for a project of this complexity it is critical to attract more people, and I think in the long run it has even a better return than coding. Alberto ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
Bob Paddock wrote: fwiw, there is a pcb-bugs mailing list with only me as the subscriber. Of course in all fairness, that list didn't exist yesterday ;) That list will get all new bug reports and updates to existing reports. Don't see it listed at any of these seemingly likely places: http://www.gpleda.org/mailinglists.html http://pcb.gpleda.org/bugs.html http://lists.sourceforge.net/lists/listinfo/pcb-bugs ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
> fwiw, there is a pcb-bugs mailing list with only me as the subscriber. Of > course in all fairness, that list didn't exist yesterday ;) That list will > get all new bug reports and updates to existing reports. Don't see it listed at any of these seemingly likely places: http://www.gpleda.org/mailinglists.html http://pcb.gpleda.org/bugs.html ? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
Duncan Drennan wrote: If the senior developers are fed projects and requirements, suitably discussed and planned, they'd be more likely to work on them. We currently work on our own desires because we know what we want, to solve our problems. That sounds nice, but the reality is quite different (understandably). Firstly, who feeds the projects and requirements to the developers? Secondly, raising ideas for discussion often ends (quickly) in the comment, "If you want it, just develop it yourself." In practice developers work on their own projects (because it is fun and fulfilling) and not on user requirements (unless they align). Someone else's requirement is more like work - why do that in your spare time? This situation is perfectly understandable, but it does raise some questions, like, How are projects identified? How are important bugs and feature requirements identified? Do non-developers have a say? (no is a valid answer, someone just needs to decide) yes and no. There are some areas where I have certainly looked for input from non-developers. But in the end, my time is volunteer and if I really don't feel like doing something, well... What is the forum to constructively discuss ideas and requirements? How should these ideas and requirements be presented? (i.e. raise the bar for presenting ideas so that it is not as simple as sending and email saying "It would be nice if...") What motivates developers to work on projects that are not their own? considering how much time I've had over the last few years to actually use any of these tools, I'd say pretty much all pcb and gaf projects I've worked on are not my own :( What gets me interested in doing any of it? It helps a lot when a lot of the legwork has been done. If I have to spend a long time trying to even reproduce a bug it gets less attention. If something adds new functionality that I think is useful and not at odds with how we'd like to proceed then that is more interesting. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
Peter Clifton wrote: On Tue, 2010-03-09 at 19:20 +, Gareth Edwards wrote: If we want to trial this model, I'm personally happy to become one of the "second-class developers" as Kai-Martin put it - to do some patch triage for gEDA tools in general, not just pcb. Sure! These things typically evolve anyway.. and are not assigned. I guess what we're saying is that someone taking an interest in patches, verifying them, and perhaps championing them to the developers - would be a useful... if that inspires people to fill that role, excellent, but I don't expect we'll be formally assigning "second-class-developers". In a much much larger project that I've been involved with for a long time, new developers need 2 sponsors who will review and approve commits for a little while. There has been talk from time to time about the notion of "second-class-developers" ~forever over there but in the end, most of us have enough sense to not mess with parts that are too far outside of our expertise. Thats why I've filed a good number of bug reports, sometime with patches attached even, for a project that I've had commit access to for well over a decade. Perhaps we can even form some teams interested to receive email updates, and get subscribed to bugs / patches in certain areas, with patches for review, or whatever. fwiw, there is a pcb-bugs mailing list with only me as the subscriber. Of course in all fairness, that list didn't exist yesterday ;) That list will get all new bug reports and updates to existing reports. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
DJ Delorie wrote: So what can we do? How can we get people with *less* experience more involved in solving this problem? Grow them? That is, introduce a group of second class developers. I don't think, this will work. The real work is to decide whether or not a patch actually improves the code. IMHO, those with the knowledge necessarily are already developers in their own right. How do we *make* first class developers if we don't grow them? We need a way for people to enter the pcb development arena. This means we need spots for developers who don't know pcb's internals, but can be exposed to them in ways that let them grow into development. A heirarchy of developers, from newbies/juniors at the "bottom" to primaries/seniors at the "top" lets us create an environment where work trickles up to the people who have enough experience to do it. Example: we have developers that only do the PNG exporter, but if something has a wider scope it gets pushed up to a developer who covers all HIDs. If it's wider, it gets pushed up again, etc. I completely agree with DJ on all of this. There are parts of pcb that I don't understand and so I don't touch (autoplacer, autorouter, lesstif HID, for example). Consider this: last time I had time to work on bugs, I wasted a lot of time going through the list finding bugs that were (1) real bugs, (2) still bugs, and (3) didn't have broken (i.e. unapplyable, uncompilable) patches. This is how I spent my lunch today and I didn't get very far. Here's an example of a place where extra help wouldn't have needed any knowledge of internals. Over the years there have been various bug reports about some of the footprints that ship with pcb. For each of those, the process becomes 1) see if a JEDEC drawing exists for the package. 2) see if there is an IPC recommendation for the footprint 3) pull vendor datasheets 4) compare what we have to these documents 5) compare the patch (if there was one) to these documents 6) adjust the existing footprint (maybe following the patch, maybe not). all told it becomes quite tedious. I figure if the footprint is being touched it needs to go under a microscope and get fixed once and for all. If the footprint change involves changing a macro used by other footprints too then add in 7) generate before and after versions of the entire library and check for changes. After all that, "just applying a supplied patch" may actually end up consuming an hour that I didn't really have. This is one that really didn't need knowledge of pcb, just the ability to carefully look at a whole bunch of mechanical drawings. Another example is when a new HID is added. Almost no existing code is touched. However, it needs to be built. Code needs to be checked for formatting (run through indent(3)), compiler warnings checked, basic functionality checked, check if there is documentation to go in the manual and pester the author for docs if none exist, add to the testsuite if the author didn't provide that, etc. I spent probably 2 hours today (my entire lunch and a chunk of my evening) on a single patch submission to get it to where I didn't feel bad about it. At this rate, it would take me a month of full time work to get through the bug and patch database I went ahead and did it on this one, but in general, it would have been useful to have extra hands to do some of these checks and to help out the author (whose work I really appreciate, this email is not meant to complain since he put in a lot of work already). -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
Am 08.03.2010 23:11, schrieb Jared Casper: I think your email is a great response to KMK and loads better than ignoring it, saying "I'm busy," or even applying it without being happy with it. I don't think it is inappropriate for devs to require contributors to follow guidelines and a certain standard (to a certain extent). This is the common way of developing the linux kernel. Patches are send to the mailing lists and the Maintainers "guide" the submitters until the patch meets the requirements. This may be a hard way for both but often it helps the submitter to provide better patches next time. BTW ineiev "guides" me across my patch on sf until his requirements are met. Frank Bergmann. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Tue, 2010-03-09 at 19:20 +, Gareth Edwards wrote: > If we want to trial this model, I'm personally happy to become one of > the "second-class developers" as Kai-Martin put it - to do some patch > triage for gEDA tools in general, not just pcb. Sure! These things typically evolve anyway.. and are not assigned. I guess what we're saying is that someone taking an interest in patches, verifying them, and perhaps championing them to the developers - would be a useful... if that inspires people to fill that role, excellent, but I don't expect we'll be formally assigning "second-class-developers". I recall one project (GTK I think), which started putting together a weekly roll-call of bugs with patches which should be sucked in, or looked at by developers. I think it was helpful. A periodic review of outstanding patches or serious bugs might also be a useful prod to developers. On Launchpad, with Ubuntu development processes tend to revolve around subscribing specific teams to bugs. If I want to get a newer package uploaded (assuming it is in Debian), I file a bug requesting a sync, then subscribe a team dealing with sync request approvals. The sync request approver adds an ACK comment, unsubscribes their group, and subscribes a group managing the archive, who then performs the sync. I think a bug tracking system like Launchpad (which is nice to use!), would help us with some of this kind of process. Bugs may be categorised with various tags, as well as the usual priority assignment and status tracking. Perhaps we can even form some teams interested to receive email updates, and get subscribed to bugs / patches in certain areas, with patches for review, or whatever. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Tue, 2010-03-09 at 21:33 +0200, Duncan Drennan wrote: > > If the senior developers are fed projects and requirements, suitably > > discussed and planned, they'd be more likely to work on them. We > > currently work on our own desires because we know what we want, to > > solve our problems. > > That sounds nice, but the reality is quite different (understandably). > Firstly, who feeds the projects and requirements to the developers? Bug reports, feature requests are two ways. Personally, I tend to work on things I will use myself (as a user of the software), or think will increase its adoption and usability. I do fix bugs, but usually only serious / crash bugs, or bugs I've introduced with my own changes. My "own projects" also include non-visible long-term-plan type code refactoring, and those mostly get done either because they stand in the way of something "cool" I fancy doing at some point, or out of satisfaction for having developed a cleaner way to write the code. > Secondly, raising ideas for discussion often ends (quickly) in the > comment, "If you want it, just develop it yourself." In practice > developers work on their own projects (because it is fun and > fulfilling) and not on user requirements (unless they align). Someone > else's requirement is more like work - why do that in your spare time? There will be overlap of course.. I think all the gEDA / PCB developers actually use the tools, so my project might also address issues other users want resolved. > This situation is perfectly understandable, but it does raise some > questions, like, > How are projects identified? > How are important bugs and feature requirements identified? > Do non-developers have a say? (no is a valid answer, someone just > needs to decide) Everyone gets a say.. only the developers (or those who choose to become developers) get to vote by writing the features ;) gEDA development is not a democracy, but I feel that the developers are willing to listen to reason, appreciate user input, and have a genuine interest in seeing the project thrive. > What is the forum to constructively discuss ideas and requirements? Email (here), IRC (#geda on irc.seul.org), private discussion.. > How should these ideas and requirements be presented? (i.e. raise the > bar for presenting ideas so that it is not as simple as sending and > email saying "It would be nice if...") If the idea is worked up to the point you can present it that completely, it sounds as if the presenter would have already done a lot of the difficult design work. The next step would be feedback, and / or writing code. The wiki is good for gathering proposals, and I've personally used google docs, google wave etc.. for such things in the past. > What motivates developers to work on projects that are not their own? Reward through appreciation and praise, knowing that others are using their work. Reward through satisfaction that the gEDA / PCB products are better as a result of their contributions Smugness at the thought we might have one-up'd a feature in a rival package... All sorts of reasons. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
> That sounds nice, but the reality is quite different (understandably). > Firstly, who feeds the projects and requirements to the developers? > Secondly, raising ideas for discussion often ends (quickly) in the > comment, "If you want it, just develop it yourself." In practice > developers work on their own projects (because it is fun and > fulfilling) and not on user requirements (unless they align). Someone > else's requirement is more like work - why do that in your spare time? > This situation is perfectly understandable, but it does raise some > questions, like, > > How are projects identified? > How are important bugs and feature requirements identified? > Do non-developers have a say? (no is a valid answer, someone just > needs to decide) > What is the forum to constructively discuss ideas and requirements? > How should these ideas and requirements be presented? (i.e. raise the > bar for presenting ideas so that it is not as simple as sending and > email saying "It would be nice if...") > What motivates developers to work on projects that are not their own? All good questions, not sure what the answers are going to be. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
> If the senior developers are fed projects and requirements, suitably > discussed and planned, they'd be more likely to work on them. We > currently work on our own desires because we know what we want, to > solve our problems. That sounds nice, but the reality is quite different (understandably). Firstly, who feeds the projects and requirements to the developers? Secondly, raising ideas for discussion often ends (quickly) in the comment, "If you want it, just develop it yourself." In practice developers work on their own projects (because it is fun and fulfilling) and not on user requirements (unless they align). Someone else's requirement is more like work - why do that in your spare time? This situation is perfectly understandable, but it does raise some questions, like, How are projects identified? How are important bugs and feature requirements identified? Do non-developers have a say? (no is a valid answer, someone just needs to decide) What is the forum to constructively discuss ideas and requirements? How should these ideas and requirements be presented? (i.e. raise the bar for presenting ideas so that it is not as simple as sending and email saying "It would be nice if...") What motivates developers to work on projects that are not their own? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On 9 March 2010 18:23, DJ Delorie wrote: > >> If developer cycles is the bottle neck, the only solution is to >> increase the number of active developers. > > That's what I'm trying to do - both reduce the bottleneck, and make it > easier to add more developers. > >From my perspective, DJ is on the money with: > We need a way for people to enter the pcb development arena. except I'd substitute "gEDA" for "pcb". I know what I want to do with gEDA, but the sheer scale of the codebase is intimidating and cooperating on patch triage/approval would be a way to actively change that. In a project of this scale, there will *always* be a hierarchy of developers. Whether that hierarchy is implicit or explicit is up to us. If we want to trial this model, I'm personally happy to become one of the "second-class developers" as Kai-Martin put it - to do some patch triage for gEDA tools in general, not just pcb. Gareth ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
> > So what can we do? How can we get people with *less* experience > > more involved in solving this problem? > > Grow them? > That is, introduce a group of second class developers. I don't > think, this will work. The real work is to decide whether or not a > patch actually improves the code. IMHO, those with the knowledge > necessarily are already developers in their own right. How do we *make* first class developers if we don't grow them? We need a way for people to enter the pcb development arena. This means we need spots for developers who don't know pcb's internals, but can be exposed to them in ways that let them grow into development. A heirarchy of developers, from newbies/juniors at the "bottom" to primaries/seniors at the "top" lets us create an environment where work trickles up to the people who have enough experience to do it. Example: we have developers that only do the PNG exporter, but if something has a wider scope it gets pushed up to a developer who covers all HIDs. If it's wider, it gets pushed up again, etc. This is the way the Linux kernel works, for example. If a patch comes in and it's simple enough, or if we trust the reviewer's opinion of it, then yeah, we just commit it and that reviewer has become a [junior] developer. If that reviewer earns enough trust, we let them commit directly. Eventually they start committing patches from other reviewers, writing their own patches, etc. > > * That group recommends tested and usable patch sets for inclusion > > in the master branch, and one of the developers pulls it in. > > Sorry, I don't get it. Either the "real" developers check the > patches again themselves. Then the procedure increases the total > load and the time lag. Or they blindly trust the lesser developers. Consider this: last time I had time to work on bugs, I wasted a lot of time going through the list finding bugs that were (1) real bugs, (2) still bugs, and (3) didn't have broken (i.e. unapplyable, uncompilable) patches. If we had someone who checked each patch and provided some feedback like "yup, I can reproduce it" and "yup, that patch does what you say", wouldn't that be better than what we have now? I, personally, could then search for such "vetted" patches and limit my involvement to answering questions like "is this the right way to solve this problem?" or "does this patch have unwanted side-effects?" > Then this group might as well do the commit themselves. Perhaps they could, if they've been around long enough for us to trust their judgement. We first need them to be around long enough, which means we need a way to get them in the loop before we can let them commit. > I think, the opposite is true. A check for unwanted side effects > certainly requires intimate knowledge of the intenrals of pcb or > gedalib for that matter. That is not needed for that group of people. Certainly, once a patch gets beyond that group, someone needs to look at it for overall good-ness and play-nice-ness. Every organization has a need for both junior and senior engineers, so that things that *can* be done by juniors are, leaving only the things that *must* be done by seniors for them. > you mean, like a debian maintainer? Similar, but platform-independent. > > to acquire simple patches for simple bugs, prioritize tasks for > > the developers based on user feedback and need, etc. > > This would only work, if developers would actually develop what > users (think they) need, rather than what developers like to use > themselves. I don't think, this is a viable assumption. If the senior developers are fed projects and requirements, suitably discussed and planned, they'd be more likely to work on them. We currently work on our own desires because we know what we want, to solve our problems. > If developer cycles is the bottle neck, the only solution is to > increase the number of active developers. That's what I'm trying to do - both reduce the bottleneck, and make it easier to add more developers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, 08 Mar 2010 21:30:39 +, 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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, 08 Mar 2010 15:10:09 -0500, DJ Delorie wrote: > I agree that PCB needs more grunt work from the (we) primary developers. (...) > So what can we do? How can we get people with *less* experience more > involved in solving this problem? Grow them? Honestly. Developers don't emerge fully adapted to the local requirements of the project. As humans are, hacker skills grow with the tasks tackled. If you want to grow the pool of developers in a voluntary environment, the only thing you can do is provide positive feedback. "Positive" does not mean, you have to enthusiastically accept each and every contribution. It means to take contributions seriously and let this be known to the contributor. With patches this translates to a timely(*) response whether or not it is going to be applied. If it ain't, a valid reason should be given. Ignorance is worse than an explicit "no". Even a "no" with no reason given is better than ignorance. By "timely" I mean days, not weeks, or months. A timely response shows that you care and thus makes the contributor feel better. Of course you can say, that you don't care. But then you should not complain if the community ceases to contribute. > How about this idea: (..) > * That group of people ONLY verify that the patches integrate with the > current master sources, build properly for the major HIDs, and > function as intended. That is, introduce a group of second class developers. I don't think, this will work. The real work is to decide whether or not a patch actually improves the code. IMHO, those with the knowledge necessarily are already developers in their own right. > * That group recommends tested and usable patch sets for inclusion in > the master branch, and one of the developers pulls it in. Sorry, I don't get it. Either the "real" developers check the patches again themselves. Then the procedure increases the total load and the time lag. Or they blindly trust the lesser developers. Then this group might as well do the commit themselves. > Knowledge of PCB internals, or even development in general, is *not* > needed I think, the opposite is true. A check for unwanted side effects certainly requires intimate knowledge of the intenrals of pcb or gedalib for that matter. > Here's a second idea that might help: (..) > * They attempt to reproduce each bug, and make sure the bug is fully > documented as far as how to reproduce, workarounds, platform > dependencies, etc. (...) > * bugs that are reproducible, and really are bugs (and not just > misunderstandings) get flagged for developers to work on. Non-bugs > get documented and closed. you mean, like a debian maintainer? > to acquire simple > patches for simple bugs, prioritize tasks for the developers based on > user feedback and need, etc. This would only work, if developers would actually develop what users (think they) need, rather than what developers like to use themselves. I don't think, this is a viable assumption. If developer cycles is the bottle neck, the only solution is to increase the number of active developers. ---<(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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, Mar 8, 2010 at 5:50 PM, DJ Delorie wrote:
>
>> When djopt is then run, it splits the overshooting line to create a
>> good line plus a 0.01 thou long "freckle".
>
> Perhaps it shouldn't do that, then :-)
>
> But keep the other code too, in case someone else does it.
OK, here's an updated patch with a more detailed explanatory comment:
diff --git a/src/djopt.c b/src/djopt.c
index 68b3641..3e85a62 100644
--- a/src/djopt.c
+++ b/src/djopt.c
@@ -75,6 +75,10 @@ RCSID ("$Id$");
#define ORIENT(x) ((x) & 0xf0)
#define DIRECT(x) ((x) & 0x0f)
+/* square of the length of the longest "freckle" */
+#define LONGEST_FRECKLE3
+#define SQ(x) ((x) * (x))
+
struct line_s;
typedef struct corner_s
@@ -1230,6 +1234,33 @@ simple_optimize_corner (corner_s * c)
}
}
check (c, 0);
+ if (c->n_lines == 1 && !c->via)
+{
+ corner_s *c0 = other_corner (c->lines[0], c);
+ if (SQ(c->x - c0->x) + SQ(c->y - c0->y) < LONGEST_FRECKLE)
+ {
+ /*
+ * Remove this line, as it is a "freckle". A freckle is an extremely
+ * short line (around 0.01 thou) that is unconnected at one end.
+ * Freckles are almost insignificantly small, but are annoying as
+ * they prevent the mitering optimiser from working.
+ * Freckles sometimes arise because of a bug in the autorouter that
+ * causes it to create small overshoots (typically 0.01 thou) at the
+ * intersections of vertical and horizontal lines. These overshoots
+ * are converted to freckles as a side effect of canonicalize_line().
+ * Note that canonicalize_line() is not at fault, the bug is in the
+ * autorouter creating overshoots.
+ * The autorouter bug arose some time between the 20080202
and 20091103
+ * releases.
+ * This code is probably worth keeping even if the autorouter bug is
+ * fixed, as "freckles" could conceivably arise in other ways.
+ */
+ dprintf ("freckle %d,%d to %d,%d\n",
+ c->x, c->y, c0->x, c0->y);
+ move_corner (c, c0->x, c0->y);
+ }
+}
+ check (c, 0);
return rv;
}
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
> When djopt is then run, it splits the overshooting line to create a > good line plus a 0.01 thou long "freckle". Perhaps it shouldn't do that, then :-) But keep the other code too, in case someone else does it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, Mar 8, 2010 at 5:17 PM, DJ Delorie wrote: > >> The patch looks good to me (although I've only skimmed it). It might >> warrant a definition of what a "freckle" is, if that term isn't use >> elsewhere. > > It looks OK to me (assuming a comment explaining *why* it's needed is > added) but I wonder if one of the other optimizations is creating > these freckles. I know one of the optimizations djopt does is to > split lines when they intersect pins/pads, perhaps that code could > just omit freckles rather than create them? (if that's what's > happening, that is). The problem is that the autorouter often creates 90 degree joints where one line overshoots the joint by 0.01 thou. When djopt is then run, it splits the overshooting line to create a good line plus a 0.01 thou long "freckle". These freckles prevent the mitering optimiser from kicking in. So yes, djopt creates the freckles, but only because the autorouter made the 0.01 thou overshoots in the first place. An ideal solution would fix the autorouter, but unfortunately my half day time budget for fixing the problem only went as far as patching djopt.c. I did have a quick try at fixing the autorouter, but ended up with strange results - so a workaround in djopt.c had to suffice. I'll tidy up the patch to add the explanation & resubmit it - but if anyone has time to fix the deeper issue in the autorouter it would of course be the better solution :) Steve Ecob ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
> The patch looks good to me (although I've only skimmed it). It might > warrant a definition of what a "freckle" is, if that term isn't use > elsewhere. It looks OK to me (assuming a comment explaining *why* it's needed is added) but I wonder if one of the other optimizations is creating these freckles. I know one of the optimizations djopt does is to split lines when they intersect pins/pads, perhaps that code could just omit freckles rather than create them? (if that's what's happening, that is). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
Since I'm in the mood to share my opinions today... :) On Mon, Mar 8, 2010 at 1:30 PM, Peter Clifton wrote: > It might seem unfair that we're (or I am) trying to third party > contributions to a higher standard than some of PCB's existing legacy > code, but assuming it doesn't completely stifle contribution, > encouraging high standard commits should aid PCB's long term quality. > I think holding new additions, either from third parties or the devs, to a higher standard than existing code is a good thing. > 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. > > Perhaps we should just apply the patch as is, and catch any bugs (if) > they appear. I don't want to discourage future contributions. > I think your email is a great response to KMK and loads better than ignoring it, saying "I'm busy," or even applying it without being happy with it. I don't think it is inappropriate for devs to require contributors to follow guidelines and a certain standard (to a certain extent). It would be nice if we could agree on a standard format and process, which I guess is part of DJ's plan. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, 2010-03-08 at 16:41 -0500, Stephen Ecob wrote: > On Mon, Mar 8, 2010 at 4:00 PM, DJ Delorie wrote: > > > >> How good are people at actually logging bugs on the SF tracker? > > > > I suspect our lack of attention to them has prompted them to be less > > good at reporting them there. > > I submitted my first PCB bug report to SF last month (#2946254), and > shortly after added a patch that fixed the problem. I must admit that > the lack of response was discouraging - but I fully appreciate that > the developers are time poor (I am also!). > > BTW thank you to Rikster, for taking the time to try the patch & > confirm that it fixes the bug, and posting the result back to SF :-) Now.. if you'd read my last mail, you might have been clued up to post a link to the source-forge bug. Given a bug, a patch, and a confirmation that it has been tried, and works... it might be one which could be applied right away! It certainly got my attention, but stopped short because finding bugs on sourceforge without a link is a ROYAL PAIN. For anyone keen, this is the link: http://sourceforge.net/tracker/?func=detail&aid=2946254&group_id=73743&atid=538811 I'm not intimately familiar with the auto-router (and don't use it), so independent verification is good. The patch looks good to me (although I've only skimmed it). It might warrant a definition of what a "freckle" is, if that term isn't use elsewhere. The optimisation is probably fine to add. A complete fix would address the issue in the auto-router as well. I'm happy to apply the patch, but I'm heading home now, as its getting late. Someone bug me to apply the patch! -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, Mar 8, 2010 at 12:10 PM, DJ Delorie wrote: > So what can we do? How can we get people with *less* experience more > involved in solving this problem? That opens up the "labor pool" so > to speak, letting the main developers work on the "hard" problems. > > How about this idea: > I like the ideas, but am not sure if there will be enough support to staff two new groups with those not already developers.It seems like step #1a would be to clean up the SF repository of patches and bugs. Given access to change things on SF I'd be willing to start trudging through and cleaning it up if there was enough reason to believe that it would eventually be used. I would also be wiling to host a git repo to apply and test patches to for eventual inclusion in the public repo, again with the assurance that eventually it would get pulled in. However, alone I'm not sure if I'd make progress fast enough to keep up. Another problem is I unfortunately don't have much time for PCB development lately (as it isn't part of my "day job"), so don't actually use the software very much, so am probably not the best tester of new patches. (but I want to help because when I do get around to doing a PCB here and there, I like to have nice open source tools to do it with :) It'd be nice to get people to volunteer for this group who use PCB on a regular basis and would actual non-trivially test patches before they were recommended for the main line. The benefit I see of being in this group is the ability to get your own patches in front of the line. :) Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, Mar 8, 2010 at 4:00 PM, DJ Delorie wrote: > >> How good are people at actually logging bugs on the SF tracker? > > I suspect our lack of attention to them has prompted them to be less > good at reporting them there. I submitted my first PCB bug report to SF last month (#2946254), and shortly after added a patch that fixed the problem. I must admit that the lack of response was discouraging - but I fully appreciate that the developers are time poor (I am also!). BTW thank you to Rikster, for taking the time to try the patch & confirm that it fixes the bug, and posting the result back to SF :-) Steve Ecob ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
> Touching hidnogui.c to remove the CRASH; statement - why is that > needed? hidnogui was designed to be a template for new HIDs, so everything crashes when called - that's how you know which function needs to be implemented next. Perhaps we need two hids - hidnogui for command-line use, and hidtemplate with all the CRASHes ? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, 2010-03-08 at 17:40 +, Kai-Martin Knaak wrote: > > I filed a bug report, I provided a patch on this list, I nagged twice on > on this about it. How come, the patch is still not applied to the source? > What should I do to get this annoying bug fixed? > Yes, I feel ignored by the developers. > No, I am not happy about it. > 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. I get a lot of email, and messages I've flagged as "unread" or "important" to remind me about them often get buried. I have 587 unread messages in my geda-user mailbox currently. Mostly from a period when I was away, but many are things I (at the time) thought I would take a second look at. Getting patches merged is sometimes about reminding people, and making things _easy_ for them.. If I want someone to build test my repository, or look at a patch - I send a link, and possibly even commands to step-by-step check out the repository, for example. I'm about 90% more likely to look at something if someone provides me a click-able link, than says "it is sourceforge bug #12345", or just says "my patch is in the bug tracker". Similarly, patches are more likely to get applied if they are small, and come with a header specifying the commit message and detailed reasoning about what the patch is for (and expected changes in behaviour). 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? The patch isn't from a local "git commit", so doesn't have a log entry explaining what it does. 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. Since I don't know what the patch's intended changes are... testing is hard! I have to reverse engineer what the patch is supposed to change, and invent a test-case. (Remember that I'm lazy... hacking on my own pet project stuff has a much lower entry level!) Trawling email on this specific patch: " A patch produced by this simple approach is attached. It moves the processing of action scripts and strings a little up. So they are executed with export options too. The file hidnogui.c needs a little patch to, to not exit if nogui_invalidate_lr is hit. " The idea seems reasonable, but the patch is potentially dangerous to me, since many things in PCB rely on the GUI being up to work. I need to see some evidence of what testing has been performed to make sure things are safe. (You might also include the detail that the patch doesn't change any behaviour for PCB invocations which aren't passed an action script). This is an example of the kind of side-effect you might expect to see because the GUI is expected to be up. " HID error: pcb called GUI function nogui_invalidate_lr without having a GUI available. 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. It might be a valid thing to do, but I want to know why - and I've probably not got the time to figure it out myself. Is this the _only_ side-effect of the patch? I know PCB's startup code has been fragile before now, this is why I'm reluctant to dive in and just apply patches changing code I'm not currently intimately familiar with. FWIW, gdb ought to show you what is happening when the CRASH call is triggered, and if it doesn't help you identify the issue - taking it up with a PCB developer might reveal something more. Some of this failure to apply patches is down to the "I'm busy - or unsure, perhaps someone knows better and will look at it..." syndrome. I'm sure everyone things this, and nothing gets done. If you want to approach someone directly (albiet this isn't the usual suggestion of how to interact), you might email me, or one of the other PCB developers, and ask to work through getting the patch committed on IRC. Peter B and I often write patches and review each others work this way. We might be able to fix whatever is causing the GUI updates, or declare that the "workaround" you proposed is in fact harmless. In any case, we don't usually /* comment out */ code we've decided to remove. It leads to a load of cruft over time. 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. It might seem unfair that we're (or I am) trying to third p
Re: gEDA-user: rant: pcb print from command line
> How good are people at actually logging bugs on the SF tracker? I suspect our lack of attention to them has prompted them to be less good at reporting them there. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
> * A group of non-developers watch for bug reports, either in the > mailing list or the SF tracker. How good are people at actually logging bugs on the SF tracker? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
I agree that PCB needs more grunt work from the (we) primary developers. At this time, I rarely have time to even work on my own pet projects. The last couple of code sprints, I've done nothing *but* bug/patch reviews, since I understand it's an important part of a project. So what can we do? How can we get people with *less* experience more involved in solving this problem? That opens up the "labor pool" so to speak, letting the main developers work on the "hard" problems. How about this idea: * Someone (or multiple people) who is NOT a developer sets up a local PCB git repository (or a branch on the master). * That respository pulls patches from SF, other git trees, and the mailing list. * That group of people ONLY verify that the patches integrate with the current master sources, build properly for the major HIDs, and function as intended. Feedback about usability, documentation, etc would be nice, but that's not the intent here. * That group recommends tested and usable patch sets for inclusion in the master branch, and one of the developers pulls it in. Obviously, we may defer the pull if we're close to a release, but we should accept greater risk otherwise. This new group would act as a sort of QA group, and they could independently grow their own heirarchy of workers and git repositories. Knowledge of PCB internals, or even development in general, is *not* needed - if such a need is seen by them, they redirect those issues to the developers. Here's a second idea that might help: * A group of non-developers watch for bug reports, either in the mailing list or the SF tracker. * They attempt to reproduce each bug, and make sure the bug is fully documented as far as how to reproduce, workarounds, platform dependencies, etc. * They can migrate non-SF bugs to SF. * bugs that are reproducible, and really are bugs (and not just misunderstandings) get flagged for developers to work on. Non-bugs get documented and closed. * They can re-verify bugs as PCB development happens, and close any that are no longer bugs. * They also do pre-release testing and post-release verification to make sure fixed bugs get verified by the originator and closed. This second group is sort of a "front line support" group, and again, knowledge of PCB development is *not* needed - you only have to be a PCB user, and by pre-processing bug reports and keeping track of what the developers *do* need to work on, you reduce our workload. Obviously, these two new groups could work together to acquire simple patches for simple bugs, prioritize tasks for the developers based on user feedback and need, etc. Just as obviously, these ideas only work if someone agrees to own them and see them through. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, Mar 8, 2010 at 9:48 AM, DJ Delorie wrote: >> Yes, I feel ignored by the developers. No, I am not happy about it. > > I agree. Those mean developers! Why can't they spend more time on > PCB and less time with their families and jobs? They should be > ashamed of themselves, not giving free software priority over things > like food and shelter. > He said nothing about developers spending too little time on the project, I think everyone understands about real life and appreciates the time put into the project. He said he was being ignored, which is an orthogonal issue. Clearly time has been spent by the developers working on PCB since Kai-Martin has submitted those patches, so it's a matter of prioritizing the time spent on the project, not prioritizing things in your own life. I believe part of the priviledge of having commit access to the public repository involves the responsibility to spend some of the small amount of time you have for the project going through and applying or denying and commenting on community contributions instead of just working on your own pet sub-project. I can't complain too loudly since all of my patches have eventually made it in, but it still irks me that this happens and I've seen a lot of good functionality and quality patches ignored. As an example Stephen and the other devs working on Icarus Verilog are fantastic about this and may provide a good example of how this could be done. Of course that may just be that Steve is able and willing to put in the extra time as the "benevolent dictator" of the project. One thing that I believe they do that could apply here (I could be wrong and maybe they will correct me) is while Steve is spending time working on a big re-work or feature, Cary forgoes the "fun part" of working on new features and does the grunt work of fixing bugs and going through community contributions and stuff. Then it will be Cary's turn next to work on something fun while Steve does some grunt work. However Steve manages to make it work, it certainly makes me want to spend more time working on Icarus every time I put a patch in, whereas I'm often hesistant to work on PCB, wondering if it will be ignored or not. Just some thoughts... carry on. :) Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
> Yes, I feel ignored by the developers. No, I am not happy about it. I agree. Those mean developers! Why can't they spend more time on PCB and less time with their families and jobs? They should be ashamed of themselves, not giving free software priority over things like food and shelter. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: rant: pcb print from command line
As noted in a different post, I just recompiled pcb from git. Unfortunately, neither git-head nor Peter Cliftons before_pours branch process action scripts when printing from the command line. The main procedure of pcb simply exports before action scripts are read. This is a known bug since more than a year. It was easy enough to fix for a low time hacker like me. So I did in February 2010. I filed a bug report, I provided a patch on this list, I nagged twice on on this about it. How come, the patch is still not applied to the source? What should I do to get this annoying bug fixed? Yes, I feel ignored by the developers. No, I am not happy about it. ---<(kaimartin)>--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
