DJ Delorie wrote:
Grow them?So what can we do? How can we get people with *less* experience more involved in solving this problem?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@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user