ETAs for libusbx operability and first release?

[Vitali Lovich]

My approach was we'll have a 3 week merge window during which people can submit requests of features they want merged in (either via patches or git branches that can be trivially rebased on mainline).  After that, we'll have a 4 week testing & bug-fixing window (i.e no features, performance improvements etc) after which we'll make a release.  Rinse & repeat.

Here's my thoughts on the priority of features I want to integrate after we make a 1.0.9 release:  

1) Windows support - I already have this in my own branch, & it seems to work well enough.  I don't see anything blocking inclusion of this code since right now the story on Windows is pathetic. 
2) Vid/Pid filtering - before any objects are created or any significant work is done, have a mechanism to filter the devices based on vid/pid.
3) Hotplug - I can provide feedback/implementations for the OSX/Linux releases as I've already done hotplug on those platforms outside of libusb.  Assuming this is a new feature that doesn't touch a lot of existing code, I don't see a lot blocking merging of this code & then resolving issues.
4) Logging improvements

-Vitali

On Jan 30, 2012, at 9:08 AM, Pete Batard wrote:

> On 2012.01.30 16:46, Segher Boessenkool wrote:
>>> Well, my problem here is that I've accumulated quite a few things that
>>> I'd like to push,
>> 
>> Yeah. Lucky for you libusb hasn't diverged much in the many months
>> you've been waiting.
> 
> Actually it did. The removal of HID was a major PITA, since hotplug was based on code that had HID. I also haven't updated the hotplug branch for months, so there might be surprises.
> 
>>> and I don't know how you guys want to prioritize them.
>> 
>> Neither do we until you present a list ;-) Let's do that after the
>> 1.0.9 release though.
> 
> Agreed. We'll need to go back to stuff that was debated on the libusb list. I remember that topology and logging callback were discussed there (the first is currently in -pbatard). There's also cross platform event support for async that we should try to implement sooner rather than later. But the rest will need to be digged up.
> 
>> so we can make the 1.0.10 release the "big mswindows changes"
>> release?
> 
> Thanks to Travis' good work, the libusbK and libusb-win32 integration shouldn't require that much of a major change actually, so, at least in terms of code, it may not be that spectacular. Should be a lot simpler than Graeme's proposal.
> 
>>> For instance, if you want a hotplug proposal right after the 1.0.9
>>> release,
>> 
>> I'd say hotplug is something for v2.
> 
> OK. I wasn't planning to push it for 1.0.10 anyway.
> 
>>> I can most certainly provide one. But that will push the
>>> libusb-win32/libusbK integration back,
>> 
>> I think it is best if you focus on this for .10 .
> 
> That's also my current plan, but it doesn't hurt making sure someone doesn't see it differently.
> 
> Regards,
> 
> /Pete
> 
> 
> _______________________________________________
> libusbx mailing list
> libusbx at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libusbx