Has the time come to start with a bug database for OpenOCD? I'm interested in trying how this will work for the community.
The bug database should have some rules of engagement to ensure that it remains effective: - it should not contain reems of bugs that has no hope of ever being addressed and that just hides things that could be addressed. - I don't want to see lots of fire and forget bug reports. If someone reports a bug, then they should make an effort to carry the burden of getting the problem sorted, even if this only means providing good detail and doing testing(e.g. bisection). - broad feature requests and plans should not go into the database. We have TODO to write up plans. - a problem should be posted and discussed(or ignored) before it is added to the database. - I'd like to see all bug reports registered and closed going to the svn mailing list. - I don't care if a bug is tracked in the community mind or in the bug report as such. We have the git log to figure out what changed between versions. - break apart larger tasks/bugs into multiple bugs (using dependencies?). -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
