For what it's worth, I agree with Johannes. I'm not a developer, other than
my small claim to fame with the PS3 addition to the xusb.c. Looking at this
debacle from an outsider's point of view, id est I have no emotional
attachments to the project ergo I'm not worried about major changes in the
pro
Hi,
On Mon, Apr 23, 2012 at 11:12:22AM +0100, Pete Batard wrote:
> We *will* deviate in an incompatible fashion sooner rather than later.
> To me, trying to delay this inevitability doesn't seem very productive.
...
> On 2012.04.23 08:40, Hans de Goede wrote:
> > IMHO in this case maintaining ABI
On 2012.04.26 06:58, Michael Plante wrote:
> I know the bug was the final thing. That's why I mentioned I thought there
> were other reasons. Remember that I had originally tried (and privately
> emailed you) about the fact that I couldn't replicate what you did.
Yes, and had no idea why that
Pete Batard wrote:
>> >>> bullshit dictatorial statements such as
>> >>> "I just don't want CR in the repo",
>> >
>> > Maybe now I'm just confused, but I thought I actually agreed with him here,
>> > partly because of some sort of bug in git, and possibly for other reasons.
>>
>> Of course, what y
Hi,
On 04/25/2012 01:52 PM, Pete Batard wrote:
> Now, with regards to what libusbx will do to sort the current
> incompatibility, and unless someone has further objections (or would
> prefer a different string), I should push a commit later on today that
> adds the static string "unused - please u
On 2012.04.25 08:21, Peter Stuge wrote:
> libusb_get_version() is an API addition in the libusb.git codebase,
> like it is in the libusbx.git codebase.
As you should know, the API addition also includes the structure
associated with the function call, so you should be careful to consider
both if
Hans de Goede wrote:
> making API + ABI changes
libusb_get_version() is an API addition in the libusb.git codebase,
like it is in the libusbx.git codebase.
> without any discussion at all!
Given the libusbx announcement I guess you may understand that there
didn't seem to be much to discuss.
Hi,
On 04/25/2012 01:12 AM, Pete Batard wrote:
> For the record we were there first with a versioning proposal, and
> Peter took the deliberate decision to go over it and force our hand.
> And yet, you're telling us that, libusbx having its hand forced is OK,
> whereas libusb having its hand force
On 24 April 2012 13:46, Michael Plante wrote:
> Pete Batard wrote:
>>> getting early user feedback wasn't that important?
>>> [...]
>>> Remember his other statement of people like himself (i.e. alleged "good"
>>> maintainers) simply being able to "feel" what was right or wrong in
>>> terms of deve
Hi,
On 04/24/2012 12:44 PM, Kustaa Nyholm wrote:
> On 4/24/12 13:13, "Pete Batard" wrote:
>
>> On 2012.04.24 07:38, Kustaa Nyholm wrote:
>>> Thanks,but I think I was just curious for the actual technical issues
>>> those new fields will cause.
>>
>> Well, to me the technical issue, is that in its
Kustaa Nyholm wrote:
>> Ah, so Peter's 'solution' (as I've said I've been tool lazy to look
>> at the code) to some perceived problem requires that the build
environment
>> invokes git ?!
No, it requires we either choose to not invoke git and make it blank, or
that we TRY to invoke git and fail gr
On 4/24/12 13:13, "Pete Batard" wrote:
>On 2012.04.24 07:38, Kustaa Nyholm wrote:
>> Thanks,but I think I was just curious for the actual technical issues
>> those new fields will cause.
>
>Well, to me the technical issue, is that in its current instance,
>Peter's patch completely ignores MS buil
On 2012.04.24 07:38, Kustaa Nyholm wrote:
> Thanks,but I think I was just curious for the actual technical issues
> those new fields will cause.
Well, to me the technical issue, is that in its current instance,
Peter's patch completely ignores MS build environments, as well as any
environment wh
On 4/24/12 03:45, "Pete Batard" wrote:
>
>If you think he's only been guilty of acting slowly, then how short your
>memory is...
>
>Remember his stance on RERO and his statement that it is possible to
>write code with no issues, and that getting early user feedback wasn't
>that important?
>Remembe
On 4/23/12 14:53, "Pete Batard" wrote:
>
>OK, maybe you are confused by the fact that I am using platform as a
>build environment rather than an actual platform system (mostly because
>Windows could be considered as 3 slightly different systems depending on
>whether your libusbx based app was buil
On 2012.04.23 13:15, Michael Plante wrote:
> Peter's recently been very accommodating about copying patches that he
> probably doesn't want in libusb, and quickly. I don't know if you've
> noticed that.
Yeah. Isn't it strange what people will do when they realize that, far
from what they believe
Hi,
On 04/23/2012 02:02 PM, Pete Batard wrote:
> Once again, if the majority votes to have the field, I'll go with it.
Ok.
> But I hope that doesn't prevent me from trying to indicate why I see it
> as a bad idea.
If you've somehow understood anything I've said as "please shut up", I'm
sorry th
Pete Batard wrote:
>> If we go this route it means that every time Peter wants us to implement
>> an half-assed solution that we shouldn't follow in the first place,
Peter's recently been very accommodating about copying patches that he
probably doesn't want in libusb, and quickly. I don't know i
On 2012.04.23 12:56, Hans de Goede wrote:
> Your really showing that you're running out of sane arguments here,
> first of all any sane version check to work around bugs will use the
> integer field rather then relying on string parsing,
Which only works fine for a project that actually releases.
Hi,
On 04/23/2012 01:53 PM, Pete Batard wrote:
> On 2012.04.23 11:57, Kustaa Nyholm wrote:
> I think Hans' and probably Michael's views are mostly with regards to a
> libusb compiled app, using a shared libusb library that has been
> replaced with libusbx.
>
> Since we're dealing with extra field,
Hi,
On 04/23/2012 12:12 PM, Pete Batard wrote:
> On 2012.04.23 08:40, Hans de Goede wrote:
>> I can understand you not being happy with these addons, but without them
>> code compiled against Peter's version of get_version may crash, so I
>> strongly
>> prefer adding them (despite your concerns)
>
On 2012.04.23 11:57, Kustaa Nyholm wrote:
>> In its current implementation, as I explained, I very much see Peter's
>> versioning buggy as it unnecessarily breaks cross-platform,
>
> This is not clear to me, someone cares to educate why and how this
> breaks cross-platform.
OK, maybe you are confu
On 4/23/12 13:12, "Pete Batard" wrote:
>If we go this route it means that every time Peter wants us to implement
>an half-assed solution that we shouldn't follow in the first place, he
>just has to arrange a way to make an app crash when switching to
>libusbx, and lo and behold, we are forced to c
On 2012.04.23 08:40, Hans de Goede wrote:
> I can understand you not being happy with these addons, but without them
> code compiled against Peter's version of get_version may crash, so I
> strongly
> prefer adding them (despite your concerns)
Well, my concerns go a bit further than that.
If we g
Hi,
On 04/22/2012 03:16 PM, Pete Batard wrote:
> On 2012.04.21 09:47, Hans de Goede wrote:
>> While talking about syncing to Peter's tree, I've noticed that he has
>> added 2 fields to our new libusb_version struct. Luckily we only return and
>> never take a pointer to that struct so we can safely
Michael Plante wrote:
> >> 2. They require invoking git during make, which of course means that if
> >> you're building from MSVC or WDK, this whole versioning falls apart.
>
> Can you add the fields to the struct, but leave them blank in this case?
Absolutely, libusb.git sets describe to the emp
Pete Batard wrote:
>> 2. They require invoking git during make, which of course means that if
>> you're building from MSVC or WDK, this whole versioning falls apart.
Can you add the fields to the struct, but leave them blank in this case? If
so, what is the downside of doing that?
Michael
Pete Batard wrote:
> Also, if say you're using TortoiseGit on Windows to fetch the repo,
> and compile in a MinGW environment where git is not available (since
> git isn't installed by default there), you will fail to populate the
> last field.
Yes. As you all know I like to optimize for the commo
On 2012.04.21 09:47, Hans de Goede wrote:
>> Next, I'd like to pick up the "Linux: Search for
>> /dev/usbdev. USB device special files" [1] patch, but
>> before I do that, I wouldn't mind if the Linux people get a chance to
>> look at it.
>
> I just reviewed the patch as found in git.libusb.org/lib
Hi,
On 04/21/2012 12:10 AM, Pete Batard wrote:
> All the patches previously mentioned have now been pushed.
> If I forgot anything, please let me know. You'll see that I merged a few
> of the Linux one-liners and also added the BSD get_speed patch from
> libusb.git.
>
> Next, I'd like to pick up t
All the patches previously mentioned have now been pushed.
If I forgot anything, please let me know. You'll see that I merged a few
of the Linux one-liners and also added the BSD get_speed patch from
libusb.git.
Next, I'd like to pick up the "Linux: Search for
/dev/usbdev. USB device special fi
31 matches
Mail list logo
