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