On Tue, May 8, 2012 at 11:28 PM, Peter Stuge <[email protected]> wrote: > Jean-Christophe PLAGNIOL-VILLARD wrote: >> I think it's time to do a new release >> this friday the merge window close >> Attention I'll close arround 8pm Shanghai Time >> follwing by 4 weeks of rc > > I disagree with this.. > > >From Tuesday to Friday is simply not reasonable for the volunteer > efforts that are ongoing and in some cases have been ongoing for a > long time to produce some sort of results.
Agree that this is a bit short notice, a week more would have been better. But it's high time for a release. > Personally I have three items of high interest which I would like to > see in the next release, in no particular order: > > 1. Efforts by Tomek and Simon toward SWD > 2. Cleaning up the total mess regarding libusb-1.0 in OpenOCD > 3. Andreas' new FTDI MPSSE driver > > By 1. I do not mean that next release must support SWD, but I do mean > that openocd.git must have developed in an agreed-upon direction. > Simon and Tomek have both put a lot of effort into this and I want to > see some of that go into the release, even if there is more work to > come. There will be more releases to come. Since we haven't even fully agreed upon a direction yet I find it highly unlikely that anything usable SWD-wise will get into mainline before we need to cut 0.7.0. I don't think we should hold off 0.7.0 indefinitely to wait for SWD. I also disapprove of merging any incomplete framework changes that could turn out to become legacy once the proper solution is in place. And I'm certain we will need a fair amount of framework changes to accommodate a clean SWD implementation. > 2. and 3. go partly hand-in-hand, since mpsse uses libusb-1.0. Don't mix them up. MPSSE is in gerrit and waiting *now* and uses the configure framework that's currently in place for libusb-1.0. Fixing that framework is a totally separate issue, which requires at maximum a single line change of the header file path in MPSSE, once the fix is in place, regardless of the type of fix. Needlessly serializing development is a bad idea. > One approach for 2. is to revert the use of libusb-1.0 in OpenOCD > completely, which affects the jlink, osbdm and stlink_usb drivers. > Another is to try to patch up the code so that it is at least not > an absolute mess. The latter requires significantly more effort. I started a branch to clean it up, before I realized I needed the async api which made it completely unusable anyway. I don't quite understand the purpose of the abstraction, it's not very useful. If you want to use libusb-1.0 with the same API as before, there's always libusb-compat. > After reverting, mpsse could be added along with somehow clean > libusb-1.0 support in the build system, and libusb-1.0 would not > be used by any other code. Don't let the revert and/or fix hold off an unrelated patchset. Even the abstraction and the build system are separate issues. The abstraction may be flawed, but the autotools support is not worse than what we've had before, for example for libftdi. The lack of pkg-config is an inconvenience. > The USB abstraction needs fixing real bad, I don't think it's > something we want to release. I urge you to have a look at it > Jean-Christophe, ideally along with the review I provided which > was unaddressed before the code was merged. I agree that it's an ugly mess but not that it's a huge problem that could hold off a release. If we get a patch to fix it in time, great. Otherwise, no big deal, we'll fix it until 0.8.0. We're not promising to keep it for all eternity just because it's been part of a release. Regards, Andreas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
