libusbx is dead, long live libusbx!

Hans de Goede hdegoede at redhat.com
Wed Mar 21 11:08:16 EDT 2012


Hi,

On 03/21/2012 03:32 PM, Pete Batard 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:
>

I too would like to thank Segher for his efforts, he certainly got he ball
rolling on this one. Thanks Segher!

> 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.
>
> 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.
>

First of all +100 for this effort, I was planning on doing pretty much the
exact same (keep the libusbx name, create a sourceforge project, use that
to do a release asap).

> 3. The plan ahead:
>
> - Hopefully starting on Monday next (or this Sunday), I would like to pick the current libusb git repo (which one?)

I think it would be best to just start with:
git://git.libusb.org/libusb.git (master)
Despite still not having done a release Peter has been doing
some good work there. And I would like us to keep syncing with
Peter's tree in the future, starting with it as base will
hopefully make that easier.

> 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)

Ack.

> - 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.

Ok, so I've 6 patches in my own local tree which I would like to
see added. I'll send these to the list after this mail, and
I'll also push my tree to:
git://people.freedesktop.org/~jwrdegoede/libusb (for109) in case
you prefer to use git pull

> - 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.

I disagree with doing a 1.0.9 release being not substantial it will
be the first release in 20 months or so. And will have tons of
bugfixes and enhancements compared to the last official libusb
release. So unless other people object I do plan to write an
announcement mail for the release once it is done, blog
about it, etc.

> 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.

Ack.

> I also don't see an issue adding more admins (except Segher, due to the current state of libusbx)

Why not Segher, I don't want us to be a fork of a fork,
just a re-start of the fork Segher started. So while I
agree with your decision to move ahead without waiting
for Segher, I don't want to exclude him. If he wants to
help out with admin tasks that is fine with me (and the
same for other contributors).

> 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.

+1

> 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.

Done :)

Regards,

Hans



More information about the libusbx mailing list