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

[DJ Delorie <dj@xxxxxxxxxxx>]

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