libusbx is dead, long live libusbx!

[Xiaofan Chen]

On Wed, Mar 21, 2012 at 10:32 PM, Pete Batard <pete at akeo.ie> wrote:
> First of all, apologies for not replying sooner. Other stuff has been
> keeping me busy, and I was kind of trying to assert how dead the current
> libusbx was, which is "very" (even the wiki seems dead). I'm quite sorry to
> see Vitali go, as I would very much have liked to have him onboard for
> libusbx, but I do appreciate that at least he let everybody know.
>
> Now, while I also appreciate what Segher tried to do, it has become fairly
> obvious that, whatever his reasons, we cannot exactly rely on him or the
> infrastructure he has been providing us with so far, so I'm going to cut to
> the chase:
>
> 1. You are hereby invited to subscribe to libusbx-devel, where I am hoping
> we can get the ball rolling again, and which can be accessed from:
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
> With Segher being our only contact for this one, and with the wiki having
> gown dark, I think a few of us will feel a lot safer having everything
> hosted on SF.net, with shared control.

I agree that SF.net is a good choice.
I've subscribed to the mailing list.

> 2. As previously indicated, I have registered the libusbx project on SF.net:
> https://sourceforge.net/projects/libusbx/ so, which comes with a mailing
> list, wiki and git, so in effect, our infrastructure is effectively sorted.
> Never wanting to be alone at the helm, I have also taken the liberty to add
> Hans and Xiaofan as project admins, with equal access. Also, if anybody
> wants a personal git-repo, such as libusbx-pbatard, to be hosted on SF that
> can be arranged (see
> http://libusbx.git.sourceforge.net/git/gitweb-index.cgi). As far as I could
> see this may require providing the ability to also update mainline, but I
> trust that, if provided access, you will confide your commits to your own
> repo, so I don't see as much of an issue.

Thanks. I do not need the code git access myself. Other than that, I
am willing to take on the project admin role, again, mainly on testing
and support role (wiki, mailing list support, etc). You should all know that
I am not a programmer and not good at git.

> 3. The plan ahead:
>
>  - Hopefully starting on Monday next (or this Sunday), I would like to pick
> the current libusb git repo (which one?) and set is as our starting point
> for libusbx. What this means is that from this will mark the official
> starting point of our fork, with any subsequent commit applied to libusbx
> being generated independently (even if reusing an original libusb patch)

Since most of the linux distro use main line libusb.git, I think that
should be the starting point.

>  - From there on, I'd like to have a couple of days (say, until Wednesday)
> to add anything we want to have to come up with something that can be
> construed as a release. Will probably create a libusbx-integration branch
> for that task or something. Consideration should be focused on what we
> identify as showstoppers, though I am planning to add the xusb sample, as I
> find it invaluable for testing.

Great. xusb is good to add.

>  - Hopefully on Thursday, we push the commits into libusbx mainline, freeze
> the code, and get things tested as an rc. Again, if the focus is with
> showstoppers, I don't expect to have so many commits that it should take us
> more than a few days to integrate them.
>
>  - Then on the Monday April 2nd (that is, unless you want to make it April
> 1st), we release libusbx-1.0.9. Personally, I am not planning to make any
> public announcement for such a release, as I consider it a testbed for our
> release process, in order to leave us with some confidence that we can get
> things going and/or identify problems outside of public view. Better do that
> while we're still unofficial than realize we want to change something a bit
> too late. Then again, I don't give much of a damn about trying to conduct
> libsubx business in secret (the mailing list is opened to anyone - there's
> no filtering), so if someone is happy enough with the 1.0.9 libusbx release
> and wants to publicize it, that'll be fine too. Still, having a something a
> bit more substantial to show for our first public release could probably
> help getting the message accross that we're in for business.

Personally I think it is good to announce the fork in libusb mailing list
since that is the main target audience.

> Of course, all of these items can be amended as requested, and, since I took
> the liberty of adding Hans and Xiaofan onboard, I would very much like to
> see a collaborative process going on at the top, rather than a single
> individual. I also don't see an issue adding more admins (except Segher, due
> to the current state of libusbx), if you would like to take on some of the
> responsibilities.

Need a Mac OS X guy for the developing side, probably Nathan.

> Anyway, no idea if this new approach is going to be more successful than the
> last, but I'm happy enough with the idea of at least having given it a try.
> Maybe it will fall just as flat, but now that we aren't bogged down with
> infrastructure concerns and shouldn't have to rely on a single individual to
> move forward, at least we can try and see the outcome.
>
> To conclude, please join the libsubx-devel mailing at SourceForge by going
> to https://lists.sourceforge.net/lists/listinfo/libusbx-devel and try to
> free up some time next week, to see if we can make at least one release of
> libusbx a reality.
>

I am glad you finally start the fork. Personally I would have forked the
project long ago if I had the code developing capability.

-- 
Xiaofan