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
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
