On 2012.10.12 17:42, Sean McBride wrote:
>> The reasoning is that issues that are not tied to hardware
>> access, such as compilation breaking on a specific platform or even
>> breakage of apps such as usbutils and OpenOCD, are going to be reported
>> fairly extensively compared to ones tied to a s
Sorry for my delayed reply...
On Mon, 1 Oct 2012 22:01:39 +0100, Pete Batard said:
>- CDash seems to be quite tied up to CMake, whereas we're using
>autotools, and we've seen after Vitali's departure that the demand to
>justify CMake maintenance wasn't really there. I'd rather avoid
>introduc
On Mon, Oct 1, 2012 at 8:06 AM, Pete Batard wrote:
> On 2012.09.30 01:04, Chuck Cook wrote:
>> One core issue that I see as a need to be addressed. Is a set of tests
>> with baseline devices which exercise all functions of every API on every
>> platform. No final release until all the test boxe
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 i
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 unrea
On Mon, Oct 1, 2012 at 8:06 AM, Pete Batard wrote:
> On 2012.09.30 01:04, Chuck Cook wrote:
>> Remove the dependency on WinUSB and the other dlls.
>
> Removing the WinUSB dependency would be a cool project, but it would
> basically mean reverse engineering the DLL and creating our own open
> sourc
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, s
On 2012.09.30 01:04, Chuck Cook wrote:
> From my point of view. I would like to see libusb-1.0 go through
> another iteration or two.
I definitely want that too, and I'm happy that Hans has agreed to do it.
If I had more scope, I wouldn't have a problem maintaining both
branches, but right now
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
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
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
Hi,
On 09/29/2012 01:16 AM, Pete Batard wrote:
> On 2012.09.28 08:49, Hans de Goede wrote:
>> 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 agree
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 coul
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 s
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
On Sat, Sep 29, 2012 at 7:16 AM, Pete Batard wrote:
>> I also know of several upstreams for other libs who have done
>> that and they are not popular with distros at all!
>
> The great thing with being a fork is we can afford being unpopular: our
> users have exceedingly easy means to switch away
On 2012.09.28 08:49, Hans de Goede wrote:
> 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 procedures for new packages,
> and once in place, there will be 2
Hi,
On 09/28/2012 02:03 AM, Pete Batard wrote:
> I'll start with some comments on distro packagers.
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 procedure
On Fri, Sep 28, 2012 at 8:03 AM, Pete Batard 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=asc&sort=due_date
>
> Yeah, I will fi
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 soon
On Thu, Sep 27, 2012 at 6:33 PM, Hans de Goede 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:
> libusbx-2.
Hi,
On 09/27/2012 11:23 AM, Xiaofan Chen wrote:
> On Thu, Sep 27, 2012 at 5:14 PM, Hans de Goede wrote:
>> As a one last note, we should probably also rename the header file, etc,
>> from libusb to libusbx for the 2.0 release.
>
> That is a good idea.
>
> Shall we just drop the "libusbx-2.0\libus
Hi,
On 09/27/2012 11:23 AM, Xiaofan Chen wrote:
> On Thu, Sep 27, 2012 at 5:14 PM, Hans de Goede wrote:
>> As a one last note, we should probably also rename the header file, etc,
>> from libusb to libusbx for the 2.0 release.
>
> That is a good idea.
>
> Shall we just drop the "libusbx-2.0\libus
On Thu, Sep 27, 2012 at 5:14 PM, Hans de Goede wrote:
> As a one last note, we should probably also rename the header file, etc,
> from libusb to libusbx for the 2.0 release.
That is a good idea.
Shall we just drop the "libusbx-2.0\libusbx.h" (libusb-1.0\libusb.h
in its current form) thingy and
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 li
Responding to Hans' replies from 2 days ago. I'll try to be brief.
1. There are 2 group of developer-users of libusb(x). The ones who want
stability, but also seem to have been just swell with a libusb that
didn't see releases in years, and the ones who want to go with the
latest and greatest a
On Tue, Sep 25, 2012 at 09:57:45AM +0200, Hans de Goede wrote:
> want to know about this>
Thanks for this, I do.
> 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 nega
2012/9/25 Hans de Goede :
> 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
>> #21, and possibly libusb_strerror), but I doubt people will want to
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
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 #21,
> and possibly libusb_strerror), but I doubt people will want to wait a week or
> so, we
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 bMaxP
31 matches
Mail list logo
