These are not specific suggestions, but rather things I'm looking for in a proposal:
- be careful about introducing new tools and techniques that everybody has to learn. One or two new tools perhaps. Especially pet tools. - avoid a 100 page document on how to develop for openocd. Find the crucial points to get right and don't dilute these with lots of small rules. - openocd will need a lot of work still. We need to avoid development gridning to a halt, yet more stability is needed. - take into consideration that we have anything from hardware developers to software developers as contributors. The fanciest software techniques could alienate those that work mainly in the embedded domain(Java, Scrum, Object Oriented programming, etc.) - focus on observable functionality and behaviour. I.e. whitespace *is* less important than SEGFAULTs... -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
