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

[DJ Delorie <dj@xxxxxxxxxxx>]

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