The git tree is tagged and has a new version stamp. Sourceforge
archives are updated, Berlios too "Real Soon Now".
This means the merge window for new OpenOCD 0.4.x features is
now closed, and the focus of all developers and helpers should
be on bugfixing and stability of the current tree.
I expect to see at least three weeks of testing before we're
ready to cut a real 0.4.x release. We've updated quite a lot
of stuff; I'm quite certain there are bugs which have not yet
been reported! (Just cutting the release turned up four...)
For developers, patch priorities become more or less:
- Fixes for regressions ... stuff that broke since 0.3.1
or older releases.
- Fixes for other bugs ... maybe it never worked, or you
don't quite know when it broke. Or it's a new feature
which doesn't yet behave quite right.
- "Polishing" ... doc updates, new config files, and so on.
Build fixes. If there's a rough edge, make it smooth!
Messages should make sense, not be too noisy, and so on.
Let's try to avoid cosmetic cleanup, but fixes for those
"didn't check for malloc returning NULL" bugs should be
OK for a while yet.
We don't want to merge patches that will destabilize things
as they fix problems, but that's not yet the top criterion.
For testers of all sorts, you should:
- Try to verify that this version works on *every* board
you have handy. New, old, not-yet-public ... all. If
OpenOCD must fail, it should do so politely. For all of
the board features which are configured in OpenOCD.
- Report things that are broken, and whether they've always
been broken. If it's a regression, please try to report
which commit introduced it; "git bisect" is easy to use if
you can reproduce the problem. (If you can't report the
commit, still report whatever it is that's broken!!)
- Also, avoid sharing only bad news. Please also report
some of the things which do *NOT* break! :)
Then for example, this would be a great time to start some new
project where you're using OpenOCD to help develop something.
Or to try out a new feature (like ARM semihosting). That would
likely be using some new things, or the old things just a bit
differently ... those are all good ways to find breakage.
Plus, if you notice some changed behavior that's not "great, that
bug is now fixed", remember that should probably show up in the
NEWS file. Did you need to change a config file? Make sure NEWS
entries are clear; and if one is missing, please draft an update.
I'd like to see if we can get a volunteer to track some of the
testing reports and post status every week or so. If nobody
volunteers quickish, I'll be even more strongly inclined to
just open up the Trac wiki at SourceForge, including **as an
experiment** its bug tracking features for that purpose...
- Dave
p.s. Just shy of a thousand changesets. Not all are bugfixes,
there's a lot of code cleanup too; but that's quite a
significant amount of improvement!
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
