libusbx is dead, long live libusbx!

[Pete Batard]

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.

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.

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)

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

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

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.

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.

Regards,

/Pete