libusbx is dead, long live libusbx!

[Michael Plante]

Pete Batard wrote:
>> please subscribe to and copy libusbx-devel at lists.sourceforge.net

Eventually.  I barely have time to reply here, and I'm not going to deal
with the inevitable posting-by-nonmember bounce right now.  If I subscribe,
I have to go setup mail filter rules in both gmail and outlook, etc etc.
Not right now.


>> On 2012.03.23 04:04, Michael Plante wrote:
>> > Did you not see Xiaofan's thread in libusb-devel on Wednesday?
>> >
>> > http://marc.info/?l=libusb-devel&m=133230593401933&w=3
>> >
>> > Many Linux distros are using that tag.
>>
>> Yes, but for a branch that we do not want to officially carry in
>> libusbx, because the tag is not against mainline.

The fact that the tag is NOT an ancestor of the current libusb.git master
head is precisely why it must be kept -- all those commits will disappear
otherwise, as they will be unreferenced.  Do you want me to have the only
backup if Peter decides to pull the plug?


>> Or are you implying that we should officialize the wip-hotplug, testing
>> and all the libusb-mplante, libubs-stuge in libusbx, because they exist
>> in libusb?

What does what exists in libusb have to do with anything?  This is about
what has been released, and what led up to it.  That doesn't even make
sense.  To answer directly, "no", but if that's not plainly obvious, then I
think we're hopelessly lost here.  None of those were ever released.


>> Better make it very
>> explicit that 1.0.9-rc3 did not originate from libusbx.
>> 1.0.9-rc3 is for libusb. We are not libusb.

1) Tags don't specify originator, unless they're signed, afaik.  Commits do,
and tags refer to commits.  So I don't know how you plan to make it
explicit.

2) I certainly hope you don't plan to reuse that name -- that would be even
worse than just deleting it, per the manpage for git-tag.

3) Keep in mind also that many people will be fetching from both
repositories anyway and will wind up with this tag even if you decide not to
have it.  Note that, for the git-uninitiated, this makes no statement about
whether the code will or will not be merged, but merely says that all tags
will be visible.  (Unless Peter pulls the plug on libusb.org when we become
wildly successful.)


>> considering that up until now there was no
>> such thing as a libusbx 1.0.9-rc3 tag,

Simple mistake, oversight, etc.  Did Segher also forget the 1.0.8 and 1.0.7
tags?  Those are libusb-only, as well.


>> Are you going to ask
>> Peter to carry such a tag in libusb's mainline repo, because then libusb
>> may get questions about libusbx-1.0.9rc1?

No, but only because Peter probably doesn't see libusbx as legitimate.  If
he did and wanted to replace it with libusb, then yes.


>> > If we plan to completely replace libusb, we
>> > will get bug reports against it
>>
>> bug that cannot be
>> reproduced in libusbx's mainline (or with libusbx's 1.0.9 release) in
>> which case we aren't going to support them, because it's a libusb issue
>> => pure 1.0.9-rc3 bugs will be directed to libusb,

We should support that exact unreproducible case it if we want to replace
libusb.  That was my premise.  Of course, support is simple:  we do exactly
what Peter does:  "have you tried the latest version?" :)


>> Triage does makes the need to carry 1.0.9-rc3 in our tree unnecessary,

No, you need to be able to identify the commit that introduced the bug.
Deleting history is unhelpful.


Thanks,
Michael