On Mon, 1 Oct 2012 01:06:05 +0100, Pete Batard said:
The one problem I see is, comprehensive unit testing is fine on paper,
when you have the resources. But I seriously see us having a major
constraint in that domain, and right now, I see rigorous comprehensive
unit testing as utterly
On 2012.10.01 16:37, Sean McBride wrote:
But that's not a reason to have *no* unit testing. :)
Yeah, and the wiki Test page should be proof enough that I don't want
that either.
All I'm trying to point out is that it's unrealistic to expect us to go
through the whole gamut of what we should
Chuck Cook wrote:
From my point of view. I would like to see libusb-1.0 go through
another iteration or two.
Sounds like a great opportunity to get more involved. Go for it!
tests with baseline devices which exercise all functions of every API
If you've been using the API then this could
Hi,
On 09/29/2012 01:16 AM, Pete Batard wrote:
On 2012.09.28 08:49, Hans de Goede wrote:
snip
This is all not necessarily disastrous :) But still
we should at least try not to burn through ABI/API incompatible releases
too soon.
Yeah, that's what I want too.
Good then we are in
Hi,
On 09/30/2012 02:04 AM, Chuck Cook wrote:
From my point of view. I would like to see libusb-1.0 go through
another iteration or two. Remove the dependency on WinUSB and the other
dlls. Get as many of the core functions working cross platform as
possible.
We may eventually need to
Building against different libraries with different interfaces on
different platforms is exactly what I want to avoid. One size fits all
would be perfect.
I was looking at the android source the other day and found a early
version of libusb in there. One library that worked on all desktops
On 2012.09.30 11:20, Hans de Goede wrote:
On 09/29/2012 01:16 AM, Pete Batard wrote:
The great thing with being a fork is we can afford being unpopular: our
users have exceedingly easy means to switch away from us if they aren't
happy. :)
I disagree strongly here, to me our first and
I agree this list is just way to big. We cannot possibly run all the
different build possibilities on all the different platforms.
Possibly this is the point where I could contribute to the project.
Select a core set of build methods along with software/hardware.
I am not really a programmer,
On 2012.09.29 02:20, Xiaofan Chen wrote:
The thing is that the fork is now much more popular than the
existing libusb among Linux distros
Alas, still not Slackware 14.0, which was released yesterday, and turns
out to be the distro I use most of the time. :)
My suggestion is to continue new
From my point of view. I would like to see libusb-1.0 go through
another iteration or two. Remove the dependency on WinUSB and the other
dlls. Get as many of the core functions working cross platform as
possible.
We may eventually need to migrate to a 2.0 version. But I would rather
not
Hi,
On 09/28/2012 02:03 AM, Pete Batard wrote:
I'll start with some comments on distro packagers.
snip
Most work for distros with multiple ABI/API versions will be in that
a parallel installable package for the new API/ABI will count as a new
package, needing to go through various distro
Hi,
tl, dr: Doing an ABI/API breaking 2.0 has my support, but lets try to
avoid doing another ABI/API breaking release soon after that.
On 09/27/2012 12:36 AM, Pete Batard wrote:
Responding to Hans' replies from 2 days ago. I'll try to be brief.
1. There are 2 group of developer-users of
On Thu, Sep 27, 2012 at 6:33 PM, Hans de Goede hdego...@redhat.com wrote:
On 09/27/2012 11:23 AM, Xiaofan Chen wrote:
Shall we just drop the libusbx-2.0\libusbx.h (libusb-1.0\libusb.h
in its current form) thingy and use libusbx2.h or things like that?
Thinking more about this, lets make it:
I'll start with some comments on distro packagers.
With regards to the bMaxPower specific issue (which I understand wasn't
your point, but still worth mentioning), they had what I consider 2 easy
ways to address it: Apply the straightforward usbutils patch we would
have provided to them as
On Fri, Sep 28, 2012 at 8:03 AM, Pete Batard p...@akeo.ie wrote:
BTW, I do not quite understand the current roadmap page with
regard to 1.1,0 and 1.1.1. I think they will not be materialized,
right?
https://github.com/libusbx/libusbx/issues/milestones?direction=ascsort=due_date
Yeah, I will
added Greg to the CC, as I don't think he is on the list and he will want to
know about this
Hi,
On 09/25/2012 01:41 AM, Pete Batard wrote:
OK, since I'd like to use the 1.1 version change as an opportunity to slide
in a couple more API changes (set transfer codes to negative, as well as
Hi,
On 09/25/2012 09:57 AM, Hans de Goede wrote:
And 2 minutes after pressing send I realize I missed one, I guess we better
put this list on the wiki somewhere or some such ...
So for the list of desired API changes, for 1.1 you've planned AFAIK:
1) The bMaxPower change
2) Make transfer
OK, since I'd like to use the 1.1 version change as an opportunity to
slide in a couple more API changes (set transfer codes to negative, as
well as #21, and possibly libusb_strerror), but I doubt people will want
to wait a week or so, we might as well try to go with a 1.0.14 that
reverts
18 matches
Mail list logo
