>> - a branch on sf >> - branch on that other web site in some repository >> - a branch on that other web site in the "testing" branch of >> the official testing repository > > In all of those cases, primarily testing *YOU* perform; > which of course should be quite exhaustive. ;)
I don't worry about stuff that I can test, that's the easy part. Test it, poof! done! I worry about stuff that I can't test. Typically I don't have the hardware, or I lack scripts, test code, coding to testing time ratio > 100x, etc. What I planned to do for mrcmcr was to keep the old commands humming along until I could get confirmation that the commands had been tested by some user who picked it up via the master branch. Perhaps never support mrcmcr in xscale, arm920t and arm966e if nobody cares... >> If there was a simple and obvious answer to this problem of >> testing and branched development, then we wouldn't be having >> this discussion. > > True, but it's important to focus on the process not > the tools used to make the process work better. > > We may want to consider that once the merge window > closes, only some release manager will commit things > to mainline. This "commit everything ASAP" mindset > is not condusive to robust and orderly releases. We've switched to git before 0.3. I think it would be great if we could agree a bit more on process before 0.3 as well... 0.3 being a milestone both in code and process then... >> I feel that OpenOCD is special in that for it's size(code and >> community) it has an insane number of different targets and >> a huge distance between developers and test hardware. > > The "special" comes more from community size, IMO, than > anything else. Anything dealing with low level hardware > stuff has those issues. I can only hope that the testing problem of access to hardware will dramatically reduce once the community grows. Another trick is of course to make more code polymorphic, no need to access actual hardware except for the *low level* stubs... ;-) -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
