My interest lies in a couple of things. I don't know what "role" this translates into though:
- recruit first rate maintainers. Actually I'm kinda done with this as it seems we have a positive feedback loop now. - commit good patches to svn quickly so as to encourage contributors - keep an eye on performance. OpenOCD has a unique capability of supporting *both* high processing power high latency(USB & TCP/IP) interfaces *and* low processing power low latency(embedded hosts). The policy of OpenOCD is that all interfaces are equal, but if an interface is no longer maintained or tested, then the community has no responsibility for it. I like that: only if we take responsibility do we have responsiblity :-) - there are, still, architectural problems with OpenOCD. I'd like to make these changes if they make the code more clear, reduces # of lines of code, more robust to changes(i.e. that changing X doesn't break Y) and there is a reasonable way to transition and retest. - target testing & qualification. I want a list of supported and tested targets/flash devices. It is not so much that I want everything to work than that I want to know *what* I can claim to work. It's OK if an older version has to be used for some obsolete target hardware. - I want to get the basic architecture and inner workings of OpenOCD right & stable so we can have long term stability in place(years). I believe that a couple of years from now we will recall the good old days of '09 when we had virtually no users, few targets and we could do what we wanted. Now is the time when we can make changes relatively easily. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
