ETAs for libusbx operability and first release?

[Segher Boessenkool]

>> That's the wrong way around! We have a release every N months, we
>> decide what goes on based on that, not the other way around. _That_
>> is the main problem with libusb IMO.
>
> 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.

> 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.  There are no other big changes waiting I
believe, so we can make the 1.0.10 release the "big mswindows changes"
release?

> If you say the only thing we should worry about for future release  
> is what has been presented, then it's all up to me to decide what  
> goes in.

Well obviously, if you do not send patches, it will not be merged.
So you can certainly stop things you wrote from going in.

> As such, I can very well choose to delay libusb0/libusbK and focus  
> on hotplug, or push other stuff like timestamped and toggleable  
> logging first, that others people may think would be better delayed.
>
> Then again, spending time and effort producing patches only to be  
> met with "we're not ready for that yet" or "couldn't you have  
> worked on feature XYZ first?" is a problem I'd like to avoid.

So discuss your big plans before you start to work on them.

> For instance, if you want a hotplug proposal right after the 1.0.9  
> release,

I'd say hotplug is something for v2.

> 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 .

> and it will also require Linux and OSX people to tend to the code  
> where needed (it's supposed to work there, but some patching/ 
> cleanup may be required). If nobody is available to sort things up  
> on OSX or Linux, we may end up with a proposal that goes nowhere or  
> have to delay a release for a few more months.

It's not going to hold up a release no matter what.  A feature either
is ready in time for a release, or it is not.

> This is why I think a little planning ahead to discuss what  
> features should be the focus of libusbx-next, can go a long way.

Of course.

Does anyone else have big things ready for .10?


Segher