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

[Kai-Martin Knaak <kmk@xxxxxxxxxxxxxxx>]

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