On Friday 08 May 2009, Zach Welch wrote:
> I hereby solicit opinions for how the OpenOCD community should be run.
More openly.
* It feels needlessly like a "closed membership club":
- Open the mailing list so patches can be submitted
by members of the "broader community", not just folk
who subscribe and want to participate/argue/etc
- Don't "just commit" patches to the trunk that have
never been presented to the list, or discussed.
(Exceptions include emergency build fixes and such.)
- Commit comments should be more informative than
the single line $SUBJECT which now seems routine.
- Improve docs on (current) architecture and
implementation. And all commands accessible
via telnet or in init scripts ... did I even
see the concept "these commands are not usable
interactively" in the documentation?
- Adopt somewhat more-formal policies, defining
roles of maintainers and submitters clearly.
They of course need to be flexible, but right
now it looks way too ad-hoc. And follow those
policies (even maintainers).
* Adopt a more distributed model. Examples might be:
- More routine posting/reviewing of [patch 1/4]
type series, sometimes including [patch 0/4] type
overviews. So that more people can know what's
going on ... the code does *NOT* stand by itself,
there are models behind it that not everyone knows.
(And if more people knew, there could be pushback
which some wouldn't like ... but usually it's a
net improvement, to have effective reviews.)
- Consider using GIT. It's not that SVN isn't
workable, but parallel development is easier
with GIT: anyone can get a writable repository.
Plus, other near-the-hardware projects like Linux
or U-Boot use it ... so the relevent developers
are probably using it already.
- This includes making it easy to create trees or
branches with experimental stuff, that's easily
testable, which may take a long time, etc.
- I'm surprised there aren't more examples of TCL
code to do things like init PLLs and memory
controllers, load-and-run programs (like u-boot
or the Linux kernel), and so on. That's a kind
of *functional* distribution ... user-contributed
code, board support, etc.
* Improve code quality. Examples at a micro level are
easy to come by, which is evidence of sloppiness.
That generally follows through to macro levels...
- Recent patches that swap "<indent><code>" with
"<indent><whitespace>" instead of just removing
those lines; or needlessly add more blank lines.
- Lots of end-of-line whitespace should just be
scrubbed ... folk seem not to be using editor
settings that highlight such goofage. Likewise,
scrub pointless blank lines (three or four in a
row, in the middle of functions).
- Inconsistent formatting ... "a=b" vs "a = b",
"if(" vs "if (", and so on. Comments.
- Consider grabbing the Linux "checkpatch.pl" and
using it ... both to sanity new check patches,
and to help clean up existing code.
- And surely there are technical cleanups too. ;)
Thats from my very limited perspective, as an experienced
developer who's just recently started (re)looking at OOCD.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
