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 Tue, Apr 24, 2012 at 8:23 AM, Peter Stuge wrote:
> Xiaofan Chen wrote:
>> once we announced the fork, suddenly Peter went into action and
>> pushed many patches
>
> I'm sorry, but that's not accurate. As I mentioned earlier in this
> thread I had included everything I could find that was pendin
Hans de Goede wrote:
> my vote *in this case* goes to adding the 2 fields.
I pushed the attached commit to libusb-stuge.git x/version_rc_describe
which is based on current libusbx.git master.
Anyone wanting to apply the change can grab the patch, or maybe save
time with:
git fetch git://git.libu
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
On 2012.04.23 18:31, Garret Kelly wrote:
> I'll agree with you that end-users and developers may prefer a fork of
> a given project, but many modern distributions offer both sides of a
> forked package, and even multiple versions of the forked packages in
> the case of the JRE. Additionally,_becaus
Xiaofan Chen wrote:
> once we announced the fork, suddenly Peter went into action and
> pushed many patches
I'm sorry, but that's not accurate. As I mentioned earlier in this
thread I had included everything I could find that was pending into
libusb.git, and I was expecting some comments on those
On Tue, Apr 24, 2012 at 4:31 AM, Hans de Goede wrote:
> Hi,
>
> On 04/23/2012 07:31 PM, Garret Kelly wrote:
>> Then we should begin actively discussing this issue with the people
>> who it _is_ up to. Preferably who're going to be doing the distro
>> packaging, because they're going to want to be
Hi,
On 04/23/2012 07:31 PM, Garret Kelly wrote:
> Then we should begin actively discussing this issue with the people
> who it _is_ up to. Preferably who're going to be doing the distro
> packaging, because they're going to want to be a part of this.
>
Short self intro: I'm a libusb developer *an
Le lundi 23 avril 2012 19:31:06, Garret Kelly a écrit :
> Please pardon my intrusion into this discussion, I'm simply an avid
> fan of the library and an interested user.
[...]
> Garret
Did I inadvertendly send one of my early response draft ? Sir, please stop
spying inside my head :p .
Agreed f
Jose Pablo wrote:
>
> I think Vincent is right. I am pretty sure you guys have a lot of good
> ideas for the library but if you keep that attitude you will not get
> it serious. It seen you guys are taking the project by force
I think that's the intent, yes.
--
Tim Roberts, t...@probo.com
Provi
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
20 matches
Mail list logo
