[Libusb-devel] libusb project -- what is the way forward

[Xiaofan Chen]

On Sun, Feb 27, 2011 at 10:49 AM, Segher Boessenkool

No, that's not the game you can play, unless you propose taking
over maintainership from Peter?

I am a bit tired to see all the arguments here without seeing any
real progress of the project regarding the Windows backend
integration.

When Peter became the maintainer, I thought he was the right
candidate (since Daniel had no much time and Peter seemed
to be interested in both Linux and Windows) and I was hoping that the
Windows backend integration would speed up and once
Peter also mentioned about a release within 2010. Now
it is 2001.

What is the way forward for the Windows backend? Maybe a
fork is in order. You can say that libusb-pbatard is a fork and
we can distribute the binaries generated from libusb-pbatard
(people are using this branch anyway as the mainline is
not ready). Then the main line does not matter any more
for the end users (developer who use libusb-1.0 Windows).

I understand this will be somewhat unfortunate and the
two projects can diverge in the long run. However, as
long as the Windows developer take part in the API core
discussion, the API can be compatible and the implementation
details does not matter too much, even some behavior
differences do not matter too much as long as they
are documented.

[Peter Stuge]

Post by Xiaofan Chen
I am a bit tired to see all the arguments here without seeing any
real progress of the project regarding the Windows backend
integration.

Even though there is not a flood of commits related to Windows code
within libusb.git I feel very strongly that progress is being made.

I agree that arguments tend to be lengthy. But it is not all bad, I
for one think that my understanding improves constantly.

Post by Xiaofan Chen
When Peter became the maintainer .. I was hoping that the
Windows backend integration would speed up and once
Peter also mentioned about a release within 2010. Now
it is 2001.

Sometimes things don't go as planned. The current state of libusb
code is better than ever, the push to libusb-stuge.git I did just
now (most of it already yesterday) is what I propose for libusb.git,
and with these commits I think it's time for a 1.0.9 tag.

(As always, I can have overlooked something, so please let me know if
that is the case!)

$ git log --oneline origin/master..
a2a37fc Windows: Remove emulated direct device access via HID API
1ce3c53 Revert libusb_strerror() until we have i18n and l10n
115eefe End thread with return instead of pthread_exit() to avoid warning on Cygwin
b64f6c8 Windows: Rename various variables named "index" to avoid shadow warnings
7454de8 Windows: Fix logic in enumeration of driver name and port number
56857df Windows: Allow claiming any interface in composite device using WinUSB
1dbb26a Windows: Allow arbitrary bConfigurationValue in config descriptors
c5847cd Darwin: Schedule isochronous transfers further in the future
2ff01d4 Darwin: Fix #65 memory leak in submit_iso_transfer()
8df9525 configure.ac: Refactor Windows backend settings into one occurence
0417e79 configure.ac: Rename AM_LDFLAGS to LTLDFLAGS and actually use them
1cc38e5 configure.ac: Clean up PC_LIBS_PRIVATE and AM_LDFLAGS
accf912 configure.ac: Call AC_CONFIG_FILES for each output file
8ab0fa9 configure.ac: Whitespace changes and trivial reordering
e3684d2 configure.ac: Quote AC_COMPILE_IFELSE() input
89e4df3 configure.ac: Define booleans to 1 when set, instead of an empty string
034f8c6 configure.ac: Clean up redundancy and fix LIBS on Linux
83d90ae configure.ac: Touch up Darwin and Cygwin OS messages
b1b62ef configure.ac: Do not use -pthread on Darwin
56372d2 configure.ac: Check for poll.h, and for nfds_t on Darwin
b23cc9d Darwin: Add support for control requests on endpoints other than 0
181878a Darwin: Add more error checking for libusb_open()
e2a80fe Core: libusb_get_next_timeout() must consider all flying transfers
db99744 Linux: Correctly catch read() errors for sysfs config descriptors
fad0a59 Linux: Refactor cancellation into a common function for all transfer types
011f1f2 Linux: Refactor discarding of URBs into a function and return all errors
26246df Linux: Set private number of URBs also for control transfers


Please review and comment. Several commits have not changed since the
patches I sent out last round.

However, I'd like to ask Nathan to look at c5847cd to check that it
isn't doing something the wrong way, because I don't fully understand
how the scheduling works there.

http://git.libusb.org/?p=libusb-stuge.git;a=commitdiff;h=c5847cd

Post by Xiaofan Chen
What is the way forward for the Windows backend?

I want to continue working on libusb.git, via improvements that are
in libusb-pbatard.git and beyond.

Post by Xiaofan Chen
You can say that libusb-pbatard is a fork

Indeed it is. But since Pete wants to converge back onto libusb.git I
don't think it's a problem.

Post by Xiaofan Chen
(people are using this branch anyway as the mainline is
not ready)

This is of course not helpful for libusb.git, because the code that
gets released will have received less testing than the fork. But I
see it as a passing problem.

Post by Xiaofan Chen
Then the main line does not matter any more
for the end users (developer who use libusb-1.0 Windows).

The question is what we as a project would like to recommend them.

Recommending that they use the fork helps them in the immediate term,
but means that libusb.git receives less attention, which is not good
for the quality of our releases.

Recommending that they use libusb.git on the other hand means that
they might not have some of the latest fixes in -pbatard.git.

The ideal would of course to have a proposed integration branch which
gets users the best of both. I'm very thankful that Pete is working
on this!

Post by Xiaofan Chen
I understand this will be somewhat unfortunate and the
two projects can diverge in the long run.

Well, basically it would be the same situation as with libusb-0.1 and
libusb-win32. IMO there are significant benefits to be made from
having just a single codebase, so I will certainly keep working on
making libusb.git excellent also on Windows, regardless of what, if
anything, happens with other repositories in the future.

Post by Xiaofan Chen
the API can be compatible and the implementation details does not
matter too much, even some behavior differences do not matter too
much as long as they are documented.

Yes, this is true, but the benefit of a common codebase is lost. As
with all forks it would lead to duplicated effort, which we all of
course want to avoid.


//Peter

[Peter Stuge]

Post by Peter Stuge
a2a37fc Windows: Remove emulated direct device access via HID API

Scratch that. This commit isn't really complete. Am fixing it up.
New email when I've pushed an updated commit.


//Peter

[Peter Stuge]

Post by Peter Stuge

Post by Peter Stuge
a2a37fc Windows: Remove emulated direct device access via HID API

Scratch that. This commit isn't really complete. Am fixing it up.
New email when I've pushed an updated commit.

Make that:

027f6cd Windows: Remove emulated direct device access via HID API

Branches master and nls have been updated.


//Peter

[Peter Stuge]

Post by Peter Stuge
027f6cd Windows: Remove emulated direct device access via HID API
Branches master and nls have been updated.

I also just added

d34f24f Windows: Touch up FileDescription and ProductName resource strings


//Peter

[Pete Batard]

Please wait until I am in a state to give a greenlight on the Windows
changes for 1.0.9 (I'll start testing when I have some time, hopefully
in a few hours, with more time tomorrow).

Also, if you wanted to overrule the consensus established on this list
with regards to HID and 1.0.9 release, you could have just flagged it
as an executive decision, and I'd have produced that patch for you (or
was I expected to throw a tantrum over executive decisions that I can
no longer influence?).

Heck, if you state, as the official libusb line, "No 1.0.10 release
without a .def generation that is not done from MS, or no 1.0.10
release with WinUSB", I'll just have to comply with this as well,
because, as official maintainer, you have the right to ignore
consensus or what the majority of users/contributors want, and define
the project's course on your own. But, when you do so, can you please
make sure you inform the list of your executive decision ("I have now
decided that X is how libusb is going to do things, and ignore any
further discussion on the matter") so that everybody is clear?

Now, the way I would have preferred to proceed with HID removal was
removing it from -pbatard first (which I am going to do next), so that
I have some idea of how it will impact features that are missing from
mainline, and then remove it from mainline.

Regards,

/Pete

[Xiaofan Chen]

Post by Pete Batard
Now, the way I would have preferred to proceed with HID removal was
removing it from -pbatard first (which I am going to do next), so that
I have some idea of how it will impact features that are missing from
mainline, and then remove it from mainline.

Personally I'd really like to see the HID backend still in libusb-pbatard
or at least in a branch. But it is your call.

[Pete Batard]

Post by Xiaofan Chen
Personally I'd really like to see the HID backend still in libusb-pbatard
or at least in a branch. But it is your call.

I know and I thought about it. But since I don't see any hope of having
HID in official any longer, and it's too engrained into windows_usb.c to
be kept in -pbatard (unlike toggleable logging or xusb, which I can
easily maintain there, even if they don't make mainline), I'd have to
maintain a branch, update it whenever I update -pbatard, and I've
already seen from hp that this was no fun to do.

I'll probably create a branch though, just before I remove HID, that
might be updated with critical fixes for a while. This way, current
users of HID will have some time to switch to HIDAPI or something else.
But that will be about it.

Regards,

/Pete

[Xiaofan Chen]

Post by Pete Batard

Post by Xiaofan Chen
Personally I'd really like to see the HID backend still in libusb-pbatard
or at least in a branch. But it is your call.

I know and I thought about it. But since I don't see any hope of having
HID in official any longer, and it's too engrained into windows_usb.c to
be kept in -pbatard (unlike toggleable logging or xusb, which I can
easily maintain there, even if they don't make mainline), I'd have to
maintain a branch, update it whenever I update -pbatard, and I've
already seen from hp that this was no fun to do.

I totally understand your position.

Post by Pete Batard
I'll probably create a branch though, just before I remove HID, that
might be updated with critical fixes for a while. This way, current
users of HID will have some time to switch to HIDAPI or something else.
But that will be about it.

That would be very good. Thanks.

[Liu Wang]

You'd be appreciated pulling me up from the following.

libusb_get_device_descriptor( devh->dev, &desc ) reports compile error: dereferencing pointer to incomplete type


int sl_init( void )
{
int r = 1;
struct libusb_device_descriptor desc;

r = libusb_init( NULL );
if (r < 0) {
fprintf( stderr, "failed to initialise libusb\n" );
return r;
}

r = find_smclcd( );
if ( r < 0 ) {
fprintf( stderr, "Could not find/open device\n" );
return r;
}

r = libusb_get_device_descriptor( devh->dev, &desc );////// pull me up here please.
if (r < 0) {
printf( "failed to get device descriptor" );
return r;
}

r = libusb_detach_kernel_driver( devh, 0 );
if ( r < 0 ) {
fprintf( stderr, "libsub_detach_kernel_driver %d %s\n", r, strerror(-r) );
return r;
}

r = libusb_claim_interface( devh, 0 );
if ( r < 0 ) {
fprintf( stderr, "usb_claim_interface error %d %s\n", r, strerror(-r) );
return r;
}
printf("claimed interface\n");


r = 0;
return r;
}

-----Original Message-----
From: Xiaofan Chen [mailto:***@gmail.com]
Sent: Tuesday, March 01, 2011 9:11 PM
To: Pete Batard
Cc: libusb-***@lists.sourceforge.net
Subject: Re: [Libusb-devel] libusb project -- what is the way forward

Post by Pete Batard

Post by Xiaofan Chen
Personally I'd really like to see the HID backend still in libusb-pbatard
or at least in a branch. But it is your call.

I know and I thought about it. But since I don't see any hope of having
HID in official any longer, and it's too engrained into windows_usb.c to
be kept in -pbatard (unlike toggleable logging or xusb, which I can
easily maintain there, even if they don't make mainline), I'd have to
maintain a branch, update it whenever I update -pbatard, and I've
already seen from hp that this was no fun to do.

I totally understand your position.

Post by Pete Batard
I'll probably create a branch though, just before I remove HID, that
might be updated with critical fixes for a while. This way, current
users of HID will have some time to switch to HIDAPI or something else.
But that will be about it.

That would be very good. Thanks.

[Xiaofan Chen]

Post by Peter Stuge

Post by Xiaofan Chen
I am a bit tired to see all the arguments here without seeing any
real progress of the project regarding the Windows backend
integration.

Even though there is not a flood of commits related to Windows code
within libusb.git I feel very strongly that progress is being made.

The problem is that many people kind of lost the interests in
libusb-1.0 and choose to use stick with libusb-win32 or
switch to WinUSB during the lengthy process.

Post by Peter Stuge
I agree that arguments tend to be lengthy. But it is not all bad, I
for one think that my understanding improves constantly.

Post by Xiaofan Chen
When Peter became the maintainer .. I was hoping that the
Windows backend integration would speed up and once
Peter also mentioned about a release within 2010. Now
it is 2001.

Sometimes things don't go as planned. The current state of libusb
code is better than ever, the push to libusb-stuge.git I did just
now (most of it already yesterday) is what I propose for libusb.git,
and with these commits I think it's time for a 1.0.9 tag.

Agreed. Except that this could have been done 5 months ago...

Post by Peter Stuge
(As always, I can have overlooked something, so please let me know if
that is the case!)
$ git log --oneline origin/master..
a2a37fc Windows: Remove emulated direct device access via HID API

I do not like this. But it is still much better than only talking and
doing nothing.

Post by Peter Stuge
1ce3c53 Revert libusb_strerror() until we have i18n and l10n
115eefe End thread with return instead of pthread_exit() to avoid warning on Cygwin
b64f6c8 Windows: Rename various variables named "index" to avoid shadow warnings
7454de8 Windows: Fix logic in enumeration of driver name and port number
56857df Windows: Allow claiming any interface in composite device using WinUSB
1dbb26a Windows: Allow arbitrary bConfigurationValue in config descriptors
c5847cd Darwin: Schedule isochronous transfers further in the future
2ff01d4 Darwin: Fix #65 memory leak in submit_iso_transfer()
8df9525 configure.ac: Refactor Windows backend settings into one occurence
0417e79 configure.ac: Rename AM_LDFLAGS to LTLDFLAGS and actually use them
1cc38e5 configure.ac: Clean up PC_LIBS_PRIVATE and AM_LDFLAGS
accf912 configure.ac: Call AC_CONFIG_FILES for each output file
8ab0fa9 configure.ac: Whitespace changes and trivial reordering
e3684d2 configure.ac: Quote AC_COMPILE_IFELSE() input
89e4df3 configure.ac: Define booleans to 1 when set, instead of an empty string
034f8c6 configure.ac: Clean up redundancy and fix LIBS on Linux
83d90ae configure.ac: Touch up Darwin and Cygwin OS messages
b1b62ef configure.ac: Do not use -pthread on Darwin
56372d2 configure.ac: Check for poll.h, and for nfds_t on Darwin
b23cc9d Darwin: Add support for control requests on endpoints other than 0
181878a Darwin: Add more error checking for libusb_open()
e2a80fe Core: libusb_get_next_timeout() must consider all flying transfers
db99744 Linux: Correctly catch read() errors for sysfs config descriptors
fad0a59 Linux: Refactor cancellation into a common function for all transfer types
011f1f2 Linux: Refactor discarding of URBs into a function and return all errors
26246df Linux: Set private number of URBs also for control transfers
Please review and comment. Several commits have not changed since the
patches I sent out last round.

The patch sets look fine to me.

And doing this sort of thing is really what a maintainer should do...

Post by Peter Stuge
However, I'd like to ask Nathan to look at c5847cd to check that it
isn't doing something the wrong way, because I don't fully understand
how the scheduling works there.
http://git.libusb.org/?p=libusb-stuge.git;a=commitdiff;h=c5847cd

Post by Xiaofan Chen
What is the way forward for the Windows backend?

I want to continue working on libusb.git, via improvements that are
in libusb-pbatard.git and beyond.

Glad to hear that.

One suggestion is to put less emphasis on the so called
"software development process". The process
need to scale down for small projects like libusb.

Post by Peter Stuge

Post by Xiaofan Chen
You can say that libusb-pbatard is a fork

Indeed it is. But since Pete wants to converge back onto libusb.git I
don't think it's a problem.

Post by Xiaofan Chen
(people are using this branch anyway as the mainline is
not ready)

This is of course not helpful for libusb.git, because the code that
gets released will have received less testing than the fork. But I
see it as a passing problem.

Hopefully this will become a true statement.

Post by Peter Stuge

Post by Xiaofan Chen
Then the main line does not matter any more
for the end users (developer who use libusb-1.0 Windows).

The question is what we as a project would like to recommend them.
Recommending that they use the fork helps them in the immediate term,
but means that libusb.git receives less attention, which is not good
for the quality of our releases.
Recommending that they use libusb.git on the other hand means that
they might not have some of the latest fixes in -pbatard.git.
The ideal would of course to have a proposed integration branch which
gets users the best of both. I'm very thankful that Pete is working
on this!

Post by Xiaofan Chen
I understand this will be somewhat unfortunate and the
two projects can diverge in the long run.

Well, basically it would be the same situation as with libusb-0.1 and
libusb-win32. IMO there are significant benefits to be made from
having just a single codebase, so I will certainly keep working on
making libusb.git excellent also on Windows, regardless of what, if
anything, happens with other repositories in the future.

In terms of libusb-0.1 and libusb-win32, it is actually not bad.
libusb-0.1 was kind of quite stable already when libusb-win32
took shape. So they really API compatible. The library part
shares a lot of codes. The driver part is anyway only specific
to Windows.

The real problem is that Stephan Meyer did not participate
in the API discussions of the original libusb-1.0, OpenUSB and
the real libusb-1.0.

Post by Peter Stuge

Post by Xiaofan Chen
the API can be compatible and the implementation details does not
matter too much, even some behavior differences do not matter too
much as long as they are documented.

Yes, this is true, but the benefit of a common codebase is lost. As
with all forks it would lead to duplicated effort, which we all of
course want to avoid.

Okay. I think this is also what Pete tried to avoid. If not he could
have forked the project long ago.

Anyway, just hope 1.09 will be out soon and future integration
can be faster.

[Nathan Hjelm]

Post by Peter Stuge
Please review and comment. Several commits have not changed since the
patches I sent out last round.
However, I'd like to ask Nathan to look at c5847cd to check that it
isn't doing something the wrong way, because I don't fully understand
how the scheduling works there.
http://git.libusb.org/?p=libusb-stuge.git;a=commitdiff;h=c5847cd

I don't quite see the point of storing the frame number. Is there a case where a subsequent call to GetBusFrameNumber returns an earlier frame?

The code won't cause any issues. Just want to understand why it might be needed.

-Nathan

[Xiaofan Chen]

Post by Peter Stuge

Post by Xiaofan Chen
I am a bit tired to see all the arguments here without seeing any
real progress of the project regarding the Windows backend
integration.

Even though there is not a flood of commits related to Windows code
within libusb.git I feel very strongly that progress is being made.
I agree that arguments tend to be lengthy. But it is not all bad, I
for one think that my understanding improves constantly.

Post by Xiaofan Chen
When Peter became the maintainer .. I was hoping that the
Windows backend integration would speed up and once
Peter also mentioned about a release within 2010. Now
it is 2001.

Sometimes things don't go as planned. The current state of libusb
code is better than ever, the push to libusb-stuge.git I did just
now (most of it already yesterday) is what I propose for libusb.git,
and with these commits I think it's time for a 1.0.9 tag.

Just wondering when there will be a 1.0.9 release?
I think the libusb-stuge patches plus a few patches
from Pete will bring 1.0.9 release. Or am I missing
something?

[Xiaofan Chen]

Post by Xiaofan Chen

Post by Peter Stuge

Post by Xiaofan Chen
I am a bit tired to see all the arguments here without seeing any
real progress of the project regarding the Windows backend
integration.

Even though there is not a flood of commits related to Windows code
within libusb.git I feel very strongly that progress is being made.
I agree that arguments tend to be lengthy. But it is not all bad, I
for one think that my understanding improves constantly.

Post by Xiaofan Chen
When Peter became the maintainer .. I was hoping that the
Windows backend integration would speed up and once
Peter also mentioned about a release within 2010. Now
it is 2001.

Sometimes things don't go as planned. The current state of libusb
code is better than ever, the push to libusb-stuge.git I did just
now (most of it already yesterday) is what I propose for libusb.git,
and with these commits I think it's time for a 1.0.9 tag.

Just wondering when there will be a 1.0.9 release?
I think the libusb-stuge patches plus a few patches
from Pete will bring 1.0.9 release. Or am I missing
something?

Another month has passed and there is no action
from Peter. I am wondering how many more month
it will require to have a 1.0.9 release.

Now I have two proposals after some private discussions
with a few interested parties.

First proposal: to have someone as release manager
(project manager) overseeing the 1.0.9 release, this
person can not be Peter. Or have someone taking
over from Peter as the lead admin of the project. My
proposal is have Peter as the Linux platform maintainer,
Pete as the Windows platform maintainer and Nathan
as the Mac OS X maintainer. And then Daniel (if he
has the time) and the new project manager to take
charge of the core and resolve the differences between
platform maintainers.

Second proposal: if the above does not work out and nothing
comes out within three months (until 15-July-2011),
we may choose to fork libusb-1.0, actually fork from
libusb-pbatard branch.

Any comments? Any more proposals? In any case, I think
the current situation is not healthy to move libusb-1.0
forward.

I know I am not an admin nor do I contribute much to
the codes side (I do contribute on the testing side), but I do
have a strong interest to see libusb-1.0 moving forward, so
do many people in the list.

[Peter Stuge]

Another month has passed and there is no action from Peter.

Not all actions are immediately visible.

As you know, Trac is mostly unusable. The issue is a bit involved,
but basically Trac makes assumptions that hold for svn but which also
means that some hacking is needed to make it work well for git
repositores.

Most issues have been solved, only filtering of commit messages for
the automatic ticket updater remains. I think I will go for a
slightly ugly hack to make it work sooner rather than later.

I think it's important to have Trac sorted, so that it's actually
possible to file bugs and such.

I am wondering how many more month it will require to have a 1.0.9
release.

I've been told that I am planning the release in 2029.

release manager

If she/he works on code why not. The code is what needs attention. I
don't think we are a big enough project to need titles, anyone can
send patches that do anything, and everyone is invited to do so.

we may choose to fork libusb-1.0, actually fork from
libusb-pbatard branch.

This is not really a "may", this has been reality for a long time
already, and it is unfortunate because it detracts from libusb.git,
meaning that what does get released has received less testing than it
could have.

To some degree the next released version will help change this, but I
think it depends more on what we recommend people to use.

In the end this situation can change only when -pbatard.git has been
aligned onto libusb.git, and all development continues based on
libusb.git and nothing else.

the current situation is not healthy to move libusb-1.0 forward.

I think I got the co-maintainer confidence in part because I am
thorough and have attention to detail. That could of course also be
misunderstood as nothing but slow. I think that since it has taken a
while from .8 to .9 it's more important to try our best to make .9
really good. But that could be wrong of course.


Back to the Trac code for now.


//Peter

[Xiaofan Chen]

Post by Peter Stuge

Another month has passed and there is no action from Peter.

Not all actions are immediately visible.
As you know, Trac is mostly unusable. The issue is a bit involved,
but basically Trac makes assumptions that hold for svn but which also
means that some hacking is needed to make it work well for git
repositores.
Most issues have been solved, only filtering of commit messages for
the automatic ticket updater remains. I think I will go for a
slightly ugly hack to make it work sooner rather than later.
I think it's important to have Trac sorted, so that it's actually
possible to file bugs and such.

That is just one example of you putting higher priority on
"process" (git, Trac, etc) than the real development...

Post by Peter Stuge

I am wondering how many more month it will require to have a 1.0.9
release.

I've been told that I am planning the release in 2029.

The important thing is whether you have a plan or not. I do not
see a plan, even if it is 2029.

Post by Peter Stuge

release manager

If she/he works on code why not. The code is what needs attention. I
don't think we are a big enough project to need titles, anyone can
send patches that do anything, and everyone is invited to do so.

Actually a release manager may not need to work too much
on codes.

Post by Peter Stuge

the current situation is not healthy to move libusb-1.0 forward.

I think I got the co-maintainer confidence in part because I am
thorough and have attention to detail. That could of course also be
misunderstood as nothing but slow. I think that since it has taken a
while from .8 to .9 it's more important to try our best to make .9
really good. But that could be wrong of course.

I think you have lost the confidence from the community...

Post by Peter Stuge
Back to the Trac code for now.

As you mentioned, the code is what needs attention, not
Trac...

[Xiaofan Chen]

Post by Peter Stuge

Post by Xiaofan Chen
we may choose to fork libusb-1.0, actually fork from
libusb-pbatard branch.

This is not really a "may", this has been reality for a long time
already, and it is unfortunate because it detracts from libusb.git,
meaning that what does get released has received less testing than it
could have.
To some degree the next released version will help change this, but I
think it depends more on what we recommend people to use.
In the end this situation can change only when -pbatard.git has been
aligned onto libusb.git, and all development continues based on
libusb.git and nothing else.

You tend to blame that the deviation of libusb-pbatard git branch and
libusb git branch (or the libusb-stuge git branch) is a big issue. But
have you ever thought why it happened in the first place. IMHO it
is because of the lack of release. Many of the emails of Pete
have the same message to you, "Release Early, Release Often".

In any case, please just pretend there is no libusb-pbatard, and
just push the current libusb-stuge (plus a few patches) to libusb.git
and release it as 1.0.9 would be very welcome. You can always
flag the Windows backend as Beta or "not ready for prime time".
Once you have a release, then libusb.git can attract attentions
from the users again.

[Pete Batard]

Post by Peter Stuge
In the end this situation can change only when -pbatard.git has been
aligned onto libusb.git, and all development continues based on
libusb.git and nothing else.

Sorry, but I call complete bullshit on that.

1. Everything from libusb.git IS in -pbatard, so clearly I don't see
what else I should pick up from libusb.git to align -pbatard onto it.

2. To my knowledge, everybody except you on this list seemed to come in
agreement that what was needed to align -pbatard and libusb.git was for
libusb.git to integrate the various patches that I have made public, and
that are up for grabs in my integration branch (which has been up for
some time, and that should apply cleanly on -stuge). When he had time
for it, Daniel didn't seem to think -pbatard was so misaligned that it
couldn't be integrated. So again, I don't see what more I need to do
there, and if you want to go *against* the general opinion, you might
want to let everybody know first.

3. One month ago, I explicitly asked you if you needed anything from me
for a release, to which you choose not to reply. So once again, it's
very hard for me to tell what I should do.

Right now, the only interpretation I can have of your "align" is if you
want to *remove* elements that you don't like from -pbatard, but for
some weird reason, don't want to be explicit about those.

We've been over this before, and the consensus on this list has been
that the release has been delayed so much that now is not a good time to
delay it further by attempting to remove stuff. If you went around the
table, I doubt you'd find anybody here who wants to introduce a new
delay by completely remodelling -pbatard, when the logical approach is
to first integrate -pbatard and then remodel if needed, with, and that
may be a novel approach to a dictatorial kind of maintenance approach,
*everybody* having a say on what should or should not be remodelled. As
you are undoubtedly aware, you had to remove HID in secrecy and place
people with a fait-accompli, because nobody else on this list thought it
made sense to delay 1.0.9 just to remove it. How many more of these
*unilateral* decisions do you want to impose on everybody?

Also, since we already have parts of -pbatard in stuge (in fact the bulk
of it is already there), I have to wonder: is the reason for the absence
of 1.0.9 release from what you have -stuge because you are planning to
*remove* things that have already been integrated by Daniel (just like
you did with HID)? If that is the case, you may want to be open about
it. You know what people usually like about Open Source? It's the fact
that all aspects from the project development, and not just the source,
is usually open as well and clearly visible.

So, once again, if you want things done a specific way, then you gotta
start to be honest about it and explicitly indicate what you need for
the release (even more so if people explicitly ask you about it),
instead of keeping silent for months, ignoring requests for transparency
on your process and keeping the general direction you want the project
to take to yourself in the hope that, somehow, you will get your way, as
that's just childish.

Obviously, if you choose to keep silent on the direction you want libusb
to take because you're not open for debate and want to reject consensus,
then we also have a real problem with a maintainer that fails the basic
expectations of the job.

Post by Peter Stuge

the current situation is not healthy to move libusb-1.0 forward.

Don't mistaken "healthy" for "the way I want", they're not the same.
And please feel to provide us with a list of the elements which you
don't find "healthy", so that we can have a debate on them and decide
whether they must be addressed before release. If, as a practician, you
think someone is ill, and you say you genuinely want to help them with a
cure, you first gotta tell them their ailments in very precise details.

Post by Peter Stuge
I think I got the co-maintainer confidence in part because I am
thorough and have attention to detail.

As e-mails on this list illustrate, you've lost that confidence from
many people now. You may want to reflect on that, and try to find out if
your minutia is not skewing the balance that people except to find in a
maintainer, between attention to detail and other qualities such as the
ability to produce timely releases.

Post by Peter Stuge
it's more important to try our best to make .9 really good.

A lot of people seem to think that the current -pbatard is good. That's
of course not to say it cannot be improved, but my understanding is that
both our users and people other than you on this list don't think it
needs to be improved so much that it should stall official releases.

As others have pointed out, and as the history of other projects like
Hurd should be a constant reminder, a perfect (or "really good") product
that comes up too late is close to worthless. Your first and foremost
consideration needs to be libusb users. The further *you* choose the
delay the 1.0.9 release, the more you make their choice of using
libusb-1.0 difficult, since they will be encountering bugs that have
long been fixed, or miss features already implemented outside of
mainline that, while not perfect, are ones that they could use.

Post by Peter Stuge
But that could be wrong of course.

I'm happy this enters your consideration.

Regards,

/Pete

[Peter Stuge]

for libusb.git to integrate the various patches that I have made
public, and that are up for grabs in my integration branch

I've been spending part of yesterday and all today trying to do this,
and the branch is indeed helpful! Thanks again for making it available!

Some commits were easy enough, some not. I'm off for a while now so
I'm sending some comments on the not so easy commits. Maybe there are
some replies by the time I get back. I'd like to tag 1.0.9 tonight.


c8d5cd3 additional HID removal cleanup

I rolled this one into my removal commit, although I left parts of
this cleanup to make libusb0 a little easier to bring in. Oh well.


ac9ed9d add gitattributes

Added, but only for the files that actually exist. Ie. *.sh *.ac *.am
The commit that adds the other files should also add the entries to
.gitattributes.


6d2b482 only ignore config.h from root directory

This should be rolled into the commit that adds config.h. Also,
better just add a negative ignore then, either to root .gitignore or
maybe in msvc/.gitignore


9ce712d removed SetupAPI, AdvAPI32 and OLE32 dependencies

Added.


3998ab2 explicit use of ANSI or WideChar calls

Added.


234ff93 add MSVC/WDK project files

Please make the .def have only one alias for each function; the one
that matches the size of parameters.

We should change how the .rc works before this commit. We should move
the version number into a small header, and have an .rc that doesn't
need to be generated and grabs version numbers from an include file,
as discussed. autoconf generates the include for non-MSVC, and
git describe could be used to create one for MSVC after checkout.

Added msvc/config.h is not in sync with config.h.in, at least
INCLUDE_DEBUG_LOGGING is different in config.h.in (it doesn't exist).

xusb is listed in a couple of the project files.

libusb.sln has a Unicode BOM. Is this a strict requirement?

I also think the commit should be split up so that there is one
commit per added build environment. (So two or three?)


30ad173 [INTERNAL - NOT FOR INTEGRATION] xusb + VS2008 project files

Ok, skipping this.


ccf8145 Windows enumeration overhaul

There's a reference to INCLUDE_DEBUG_LOGGING here too. And all added
functions seem Windows-only - I think they should be static.

Would you like the new enumeration to be in next release or do you
prefer to first have one release with the old code? It might be
helpful to catch some problems?


e4a1cee use _open() and _close() rather than _open_osfhandle() and CloseHandle()
f4060de fixed default WinUSB timeout and ineffective policy settings
ade9d83 prevent set_configuration request from being sent using WinUSB
88d6878 minor code improvements

These all look great.


Thanks again!


//Peter

[Xiaofan Chen]

Post by Peter Stuge
I'd like to tag 1.0.9 tonight.

Finally! Thanks a lot.

[Xiaofan Chen]

Post by Peter Stuge
ccf8145 Windows enumeration overhaul
There's a reference to INCLUDE_DEBUG_LOGGING here too. And all added
functions seem Windows-only - I think they should be static.
Would you like the new enumeration to be in next release or do you
prefer to first have one release with the old code? It might be
helpful to catch some problems?

I used to have some reservation about this one. But my tests
shows they are working fine. Since this first release of Windows
backend will be labeled as experimental, I think this should be
included so as to get more tests. Also I think as per Pete this is
also good for the future Hotplug discussions.

[Pete Batard]

Post by Peter Stuge
I'd like to tag 1.0.9 tonight.

If that depends on having everything you list below, that's unlikely to
happen. I'll see what I can do, but providing what you request, while
also ensuring it isn't rushed, might take a fair amount of time (which
will be in short supply on my end until Tuesday next).

If at all possible, could we please avoid this "nothing happens for
months, then everything gets rushed in a matter of days" cycle? I'm
delighted to see movement at long last, but some of the stuff you want
for Windows cannot happen in a day, even more so as I have to start with
a different -stuge base. I can only hope that some day you'll get to be
the one at the other end of a repo that goes against the git established
wisdom of not reversing public commits...

Again, before you hit on a 1.0.9 release with patches from my
integration_temp branch, which may take some time to refactor and test,
could we *please* have a 1.0.9 release with as little extra Windows as
possible, so that people can use all the good non-Windows stuff that's
been sitting around for so long in a release?

Also note that, before you go ahead with a release, I'd also like to
have some heads up with whatever you plan to push as official, to make
sure that everything there gets tested on all the Windows environment we
support.

Post by Peter Stuge
c8d5cd3 additional HID removal cleanup
I rolled this one into my removal commit, although I left parts of
this cleanup to make libusb0 a little easier to bring in. Oh well.

I diffed the new patch against the previous one, but I don't see any
part from the cleanup addon that you didn't pick. Can you elaborate on
what you actually left out?

Post by Peter Stuge
ac9ed9d add gitattributes
Added, but only for the files that actually exist. Ie. *.sh *.ac *.am
The commit that adds the other files should also add the entries to
.gitattributes.

OK

Post by Peter Stuge
6d2b482 only ignore config.h from root directory
This should be rolled into the commit that adds config.h. Also,
better just add a negative ignore then, either to root .gitignore or
maybe in msvc/.gitignore

As you wish.

Post by Peter Stuge
9ce712d removed SetupAPI, AdvAPI32 and OLE32 dependencies
3998ab2 explicit use of ANSI or WideChar calls
Added.

Thanks.

Post by Peter Stuge
234ff93 add MSVC/WDK project files

Will reply downthread.

Post by Peter Stuge
We should change how the .rc works before this commit. We should move
the version number into a small header, and have an .rc that doesn't
need to be generated and grabs version numbers from an include file,
as discussed. autoconf generates the include for non-MSVC, and
git describe could be used to create one for MSVC after checkout.

I need to review the proposal you've just committed in -stuge and see
how it impacts -pbatard. As you should be aware, I'm using versioning
quite extensively, including a nano, so I need to swallow this thing and
digest it into my branch, before I can go back to pushing patches
against -stuge. If at all possible, I'd propose to remove this change
for 1.0.9 and instead wait for 1.0.10 to do it, as it would speed up the
rest of the integration.

Post by Peter Stuge
Added msvc/config.h is not in sync with config.h.in, at least
INCLUDE_DEBUG_LOGGING is different in config.h.in (it doesn't exist).
xusb is listed in a couple of the project files.

Will fix that.

Post by Peter Stuge
libusb.sln has a Unicode BOM. Is this a strict requirement?

The BOM is created by Visual Studio when it generates the file.
Can't tell for VS2005 or VS2008 if it's a strict requirement, as I don't
have these installed now. For VS2010, I can tell you it's not an
absolute requirement, but you will lose the ability to double click on
the .sln to open the project in VS, and instead have to first launch VS
and navigate to the solution, which is very inconvenient.

As such, I don't think we can escape the BOM.

My understanding is that git should have no issue with BOMs on "text"
files. Why would you want to remove it?

Post by Peter Stuge
I also think the commit should be split up so that there is one
commit per added build environment. (So two or three?)

That would be 3, unless you want to add an extra commit for the common
stuff in MSVC, else, it needs to be attached to any of the 3, which
kinda breaks the whole point of making the addon of the build envs
independent, since the 2 others will depend on the first one.

As such, I'd say this is a waste of time, so I'm not planning to do it.
If you see that as a showstopper, please justify.

Post by Peter Stuge
ccf8145 Windows enumeration overhaul
There's a reference to INCLUDE_DEBUG_LOGGING here too. And all added
functions seem Windows-only - I think they should be static.

OK, will look into it.

Post by Peter Stuge
Would you like the new enumeration to be in next release or do you
prefer to first have one release with the old code? It might be
helpful to catch some problems?

I want whatever helps getting 1.0.9 ASAP, and I suspect _not_
integrating new_enum might (unless you ask me to refactor subsequent
patches to avoid it). But as Xiaofan pointed out, new_enum can hardly be
considered risky for release by now, especially when the Windows backend
is to be flagged EXPERIMENTAL.

Regards,

/Pete

[Peter Stuge]

Post by Pete Batard

Post by Peter Stuge
I'd like to tag 1.0.9 tonight.

If that depends on having everything you list below, that's unlikely to
happen.

I don't know if the commits are important enough to wait on - that's
basically what I am asking you. :)

Post by Pete Batard
I'll see what I can do, but providing what you request, while
also ensuring it isn't rushed, might take a fair amount of time (which
will be in short supply on my end until Tuesday next).

Nod. I've spent most of the weekend just on getting to current -stuge
state. Many of the commits have needed a lot of time.

Post by Pete Batard
If at all possible, could we please avoid this "nothing happens for
months, then everything gets rushed in a matter of days" cycle?

Yes, sorry for the burstiness. I'm really fine with both ways: tag
sooner with fewer of the fixes, or wait for fixes and tag next week.

However, as I have pointed out multiple times, it is in no way
neccessary (I think it's very unfortunate) that I am the only one
doing review and sending comments on patches so that they can be
touched up. All would be quicker if others had gotten to this before
me. I'm absolutely not pointing a finger at you Pete because you're
the one creating the commits, but I am pointing at everyone else who
craves a release. Please help with review and comments if you can.

Of course everyone will not notice the same things, but I'm sure that
everyone on this list would have noticed the things I pointed out.

(My thinly veiled agenda is to still be able to be bursty, albeit
maybe not as severely, in any case without it causing a problem. With
more reviews done before me it gets increasingly likely that the
release is just a matter of pushing a tag. That would be *my* dream
scenario at least! :)

Post by Pete Batard
I'm delighted to see movement at long last, but some of the stuff you want
for Windows cannot happen in a day,

Maybe I can help get it done quicker.

Post by Pete Batard
even more so as I have to start with a different -stuge base.

If you like I can help with the rebasing. What is the repo state that
you would prefer to start working from?

Post by Pete Batard
I can only hope that some day you'll get to be the one at the other
end of a repo that goes against the git established wisdom of not
reversing public commits...

It shouldn't have to be too painful. But let me know and I'll put
myself in your shoes.

Post by Pete Batard
Again, before you hit on a 1.0.9 release with patches from my
integration_temp branch, which may take some time to refactor and test,
could we *please* have a 1.0.9 release with as little extra Windows as
possible, so that people can use all the good non-Windows stuff that's
been sitting around for so long in a release?

No problem with me. I just wanted to get as much of your work in there
as possible.

Post by Pete Batard
Also note that, before you go ahead with a release, I'd also like to
have some heads up with whatever you plan to push as official, to make
sure that everything there gets tested on all the Windows environment we
support.

Yes that is certainly fair. If I was a bit too eager with just one
day then let me know what timeframe we should try for? (Maybe push
it just this once though so we get the damn thing out?)

Post by Pete Batard

Post by Peter Stuge
c8d5cd3 additional HID removal cleanup
I rolled this one into my removal commit, although I left parts of
this cleanup to make libusb0 a little easier to bring in. Oh well.

I diffed the new patch against the previous one, but I don't see any
part from the cleanup addon that you didn't pick. Can you elaborate on
what you actually left out?

Sorry, I meant that in the original patch I deliberately left out some
of the things that you cleaned up, because I thought it might help
libusb0. But it's not that big of a deal so now I just grabbed all
your fixes.

Post by Pete Batard

Post by Peter Stuge
We should change how the .rc works before this commit. We should move
the version number into a small header, and have an .rc that doesn't
need to be generated and grabs version numbers from an include file,
as discussed. autoconf generates the include for non-MSVC, and
git describe could be used to create one for MSVC after checkout.

I need to review the proposal you've just committed in -stuge and see
how it impacts -pbatard. As you should be aware, I'm using versioning
quite extensively, including a nano, so I need to swallow this thing and
digest it into my branch,

I did have it in mind. Have you also been passing the nano through
autoconf? For MSC the nano should just need to be addad as #define
to version.h and then used in libusb-1.0.rc. Since the .rc has a nano
in the numerical versions maybe we should just always add the nano
just with a comment that it's only ever used for Windows? That way it
would be easy for you to patch a number in there. You could even
define it on the compile command line.

Post by Pete Batard
If at all possible, I'd propose to remove this change for 1.0.9 and
instead wait for 1.0.10 to do it, as it would speed up the rest of
the integration.

The .rc commit is only important in anticipation of the MSC build
files, but I just don't know my way around those build files so well
yet and I also needed to sleep a bit, so the .rc fix is all I got to.

Post by Pete Batard

Post by Peter Stuge
libusb.sln has a Unicode BOM. Is this a strict requirement?

The BOM is created by Visual Studio when it generates the file.

..

Post by Pete Batard
will lose the ability to double click on the .sln to open the
project in VS,

That's useless. In with the BOM.

Post by Pete Batard

Post by Peter Stuge
I also think the commit should be split up so that there is one
commit per added build environment. (So two or three?)

That would be 3, unless you want to add an extra commit for the common
stuff in MSVC, else, it needs to be attached to any of the 3, which
kinda breaks the whole point of making the addon of the build envs
independent, since the 2 others will depend on the first one.
As such, I'd say this is a waste of time, so I'm not planning to do it.
If you see that as a showstopper, please justify.

I think it's good hygiene. I would have done this already but yeah a
little worried I'll break something. I'm happy to have a go though.

You're right, it makes sense to have the libusb.h fixes for MSC first
in a separate commit.

Post by Pete Batard

Post by Peter Stuge
Would you like the new enumeration to be in next release or do you
prefer to first have one release with the old code? It might be
helpful to catch some problems?

I want whatever helps getting 1.0.9 ASAP, and I suspect _not_
integrating new_enum might (unless you ask me to refactor subsequent
patches to avoid it). But as Xiaofan pointed out, new_enum can hardly be
considered risky for release by now, especially when the Windows backend
is to be flagged EXPERIMENTAL.

I don't think new enum is risky, I don't know enough to say, I'm
basically asking if you think it's at all useful to get testing on
the old code. If not (as I suspect) and the fixes are quick enough
then let's put newenum out there straight away.

Again, I can help out with this lot today, but I'm afraid I'm pretty
badly jammed later in the week. :\


//Peter

[Pete Batard]

Post by Peter Stuge
I don't know if the commits are important enough to wait on - that's
basically what I am asking you. :)

At this stage, nothing is important enough that it can't be waited on.
If anything is going to delay an 1.0.9 release that you want to push
forward, it can be left out.

Post by Peter Stuge

Post by Pete Batard
I'll see what I can do, but providing what you request, while
also ensuring it isn't rushed, might take a fair amount of time (which
will be in short supply on my end until Tuesday next).

Nod. I've spent most of the weekend just on getting to current -stuge
state. Many of the commits have needed a lot of time.

OK. You can always try to pop a request for help if you think that
something is time consuming and should be redone.

Post by Peter Stuge

Post by Pete Batard
If at all possible, could we please avoid this "nothing happens for
months, then everything gets rushed in a matter of days" cycle?

Yes, sorry for the burstiness. I'm really fine with both ways: tag
sooner with fewer of the fixes, or wait for fixes and tag next week.

I'm with sooner, obviously.

Post by Peter Stuge
However, as I have pointed out multiple times, it is in no way
neccessary (I think it's very unfortunate) that I am the only one
doing review and sending comments on patches so that they can be
touched up. All would be quicker if others had gotten to this before
me. I'm absolutely not pointing a finger at you Pete because you're
the one creating the commits, but I am pointing at everyone else who
craves a release. Please help with review and comments if you can.

I think that's a fair point, but I also think it would be easier if
there was a single official integration branch with what's meant to be
added to official.

Currently, -stuge seems to be filling part of that role (maybe creating
an official "integration" branch off mainline would be more explicit
then using a personal repo, especially for new contributors), but if the
point was to get the Windows integration patch that come on top of
-stuge reviewed, I don't think expecting people to juggle with 2
personal repos and branches will help. I guess I should have posted the
patches on the mailing list then, but in that case, we might want to
make it official that there is both a release and an integration branch,
and that patches need to be posted and reviewed for any of them
(preferably ontop of latest integration), and not just release.

Post by Peter Stuge
(My thinly veiled agenda is to still be able to be bursty, albeit
maybe not as severely, in any case without it causing a problem. With
more reviews done before me it gets increasingly likely that the
release is just a matter of pushing a tag. That would be *my* dream
scenario at least! :)

If you want to be bursty that's fine, as long as you let us know. I'd
suggest delegating Segher to be an official second in command for the
times outside of your bursts of burst, as I believe some form of
official or semi-official guidance is needed regularly, and as problems
arise when there's no maintainer around.

Post by Peter Stuge

Post by Pete Batard
I'm delighted to see movement at long last, but some of the stuff you want
for Windows cannot happen in a day,

Maybe I can help get it done quicker.

Thanks for the offer. If there's anything, I'll let you know.

Post by Peter Stuge

Post by Pete Batard
even more so as I have to start with a different -stuge base.

If you like I can help with the rebasing. What is the repo state that
you would prefer to start working from?

I don't rebase. I found it was quicker for me not to, as I've had too
many of issues with conflict resolution. Eventhough I'm supposed to know
how to resolve said conflicts, and TGit is great help to visualize them,
I still manage to screw that resolution over and over and over, and end
up wasting time creating corrective patches. Therefore, I'd rather deal
with stable and bitesize stuff and spend time on something else. Not so
say that once the gap between -pbatard and mainline has been bridged,
I'm not gonna go back to trying my hand at rebasing again, but I've I
firmly believe that corrective patches, even it's to revert stuff on
commits that have not been integrated into official yet, are not the end
of the world. Why else would we be using VCSs in the first place?

Post by Peter Stuge

Post by Pete Batard
I can only hope that some day you'll get to be the one at the other
end of a repo that goes against the git established wisdom of not
reversing public commits...

It shouldn't have to be too painful. But let me know and I'll put
myself in your shoes.

OK. I'll see what comes up when I try my hand at rebuilding patches
against the new stuge.

Post by Peter Stuge

Post by Pete Batard

Post by Peter Stuge
We should change how the .rc works before this commit. We should move
the version number into a small header, and have an .rc that doesn't
need to be generated and grabs version numbers from an include file,
as discussed. autoconf generates the include for non-MSVC, and
git describe could be used to create one for MSVC after checkout.

I need to review the proposal you've just committed in -stuge and see
how it impacts -pbatard. As you should be aware, I'm using versioning
quite extensively, including a nano, so I need to swallow this thing and
digest it into my branch,

I did have it in mind. Have you also been passing the nano through
autoconf? For MSC the nano should just need to be addad as #define
to version.h and then used in libusb-1.0.rc. Since the .rc has a nano
in the numerical versions maybe we should just always add the nano
just with a comment that it's only ever used for Windows? That way it
would be easy for you to patch a number in there. You could even
define it on the compile command line.

That would help. Will let you know if that's needed.

Wasn't there some discussion where you said you wouldn't mind having
some part of the git commit hash as the nano, to help us identify builds
outside of official releases? I don't think I'm the only one here who
could use a nano.

Post by Peter Stuge

Post by Pete Batard

Post by Peter Stuge
I also think the commit should be split up so that there is one
commit per added build environment. (So two or three?)

That would be 3, unless you want to add an extra commit for the common
stuff in MSVC, else, it needs to be attached to any of the 3, which
kinda breaks the whole point of making the addon of the build envs
independent, since the 2 others will depend on the first one.
As such, I'd say this is a waste of time, so I'm not planning to do it.
If you see that as a showstopper, please justify.

I think it's good hygiene.

Yeah, I agree it would be nice. But there's nice. And then there's "why
aren't we spending time on hotplug and other stuff, instead of git
cosmetics?"

Post by Peter Stuge
You're right, it makes sense to have the libusb.h fixes for MSC first
in a separate commit.

Great, so now you want 4. Should have just shut my big mouth, and
discreetly squeezed it in into one of the 3...

Post by Peter Stuge

Post by Pete Batard

Post by Peter Stuge
Would you like the new enumeration to be in next release or do you
prefer to first have one release with the old code? It might be
helpful to catch some problems?

I want whatever helps getting 1.0.9 ASAP, and I suspect _not_
integrating new_enum might (unless you ask me to refactor subsequent
patches to avoid it). But as Xiaofan pointed out, new_enum can hardly be
considered risky for release by now, especially when the Windows backend
is to be flagged EXPERIMENTAL.

I don't think new enum is risky, I don't know enough to say,

By now, it isn't.

Post by Peter Stuge
I'm
basically asking if you think it's at all useful to get testing on
the old code.

Nope.

Post by Peter Stuge
If not (as I suspect) and the fixes are quick enough
then let's put newenum out there straight away.

If you want new_enum in then that settles it: 1.0.9 is not going to
happen this week.

Post by Peter Stuge
Again, I can help out with this lot today, but I'm afraid I'm pretty
badly jammed later in the week. :\

Same here. I'll be out of touch from Thurs -> Tue, so any release I can
help with has to happen today or tomorrow.

Regards,

/Pete

[Pete Batard]

Post by Peter Stuge
We should change how the .rc works before this commit. We should move
the version number into a small header, and have an .rc that doesn't
need to be generated and grabs version numbers from an include file,
as discussed.

Actually, I forgot I did just that in -pbatard on 2010.09.21.
That was probably around the time we discussed these things.

As shown in [1] I'd also suggest:
- removing the _debug.dll case, since we no longer suffix
- adding the an URL to libusb.org in the comments (Windows explorer
doesn't display that property by default yet, but maybe it will one day)
- adding a "\0" after the version macro. I would have to seek that
information back, but from what I recall when looking up some examples,
without the trailing NULs, some configurations may experience problems.

I'd also switch to using a specific libusb_version.h name rather than
the ultracommon version.h, since when developers use and mix various
projects, it's nice to be able to tell from the file opened in the IDE
which "version.h" actually belongs to which project.

Since I need to add the nano anyway, I'll provide these patches with my
changes to version.h. Not gonna do the renaming, though, if you want to
go with that, I'd like to know it ASAP, since I'm going to rename my
libusb_version.h to version.h in -pbatard otherwise.

Regards,

/Pete

[1]
http://git.libusb.org/?p=libusb-pbatard.git;a=commitdiff;h=0c3fdebd60230a95188d687ee46cff788e303072;js=1

[Pete Batard]

Just so you know, cygwin seems to insert carriage returns (0x0D) when
creating the version strings => configure breaks on cygwin when using
-stuge. I'll see what I can I can fix that.

Regards,

/Pete

configure:3221: checking whether the C compiler works
configure:3243: gcc conftest.c >&5
conftest.c:4:25: warning: missing terminating " character
conftest.c:5: error: expected identifier or '(' before numeric constant
conftest.c:7:1: warning: missing terminating " character
conftest.c:7: error: missing terminating " character
conftest.c:8:24: warning: missing terminating " character
conftest.c:11:1: warning: missing terminating " character
conftest.c:11: error: missing terminating " character
conftest.c:15:17: warning: missing terminating " character
conftest.c:18:1: warning: missing terminating " character
conftest.c:18: error: missing terminating " character
configure:3247: $? = 1
configure:3285: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libusb"
| #define PACKAGE_TARNAME "libusb"
| #define PACKAGE_VERSION "1
.0
.8
"
| #define PACKAGE_STRING "libusb 1
.0
.8
"
| #define PACKAGE_BUGREPORT "libusb-***@lists.sourceforge.net"
| #define PACKAGE_URL "http://www.libusb.org/"
| #define PACKAGE "libusb"
| #define VERSION "1
.0
.8
"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3290: error: in `/cygdrive/d/libusb-stuge':
configure:3292: error: C compiler cannot create executables

[Peter Stuge]

Post by Pete Batard
Just so you know, cygwin seems to insert carriage returns (0x0D) when
creating the version strings => configure breaks on cygwin when using
-stuge.

Ooh fun.

Does version.h have CRLF line endings, while configure.ac has LF?
That would explain what is going on. The m4 macro in configure.ac
doesn't explicitly eat CR so the line endings would have to match.
Even if they do, maybe m4 doesn't understand CR.

Post by Pete Batard
I'll see what I can I can fix that.

Does this change help?

+++ b/configure.ac
@@ -2,7 +2,7 @@ dnl These m4 macros are whitespace sensitive and break if moved around much.
m4_define([LU_VERSION_H], m4_include([libusb/version.h]))
m4_define([LU_DEFINE_VERSION_ATOM],
[m4_define([$1], m4_bpatsubst(m4_bregexp(LU_VERSION_H,
- [^#define *$1 *\(.*\)
+ [^#define *$1 *\([0-9]*\).*



//Peter

[Pete Batard]

Post by Peter Stuge
+ [^#define *$1 *\([0-9]*\).*

Yeah, I've been thinking along the same line. Wasted some time trying \d
which m4's regexp doesn't seem to like for some reason. On the other
hand \s seems to be fine for whitespaces (at least on cygwin and MinGW)
so I've added those, since someone is bound to try to use a tab. I've
also added provision for end of line comments while I was there.

Haven't tested the attached on Linux. Can you confirm that it's good too?

Regards,

/Pete

[Peter Stuge]

Post by Peter Stuge
+ [^#define *$1 *\([0-9]*\).*

..

\s

Good one.

I've also added provision for end of line comments while I was there.

That was the purpose of patsubst, but since now only leading digits
will match anyway we can get rid of the patsubst. Good!

Haven't tested the attached on Linux. Can you confirm that it's good too?

Yes principle looks good and it works. The following should still
work on cygwin:

@@ -1,14 +1,11 @@
dnl These m4 macros are whitespace sensitive and break if moved around much.
m4_define([LU_VERSION_H], m4_include([libusb/version.h]))
m4_define([LU_DEFINE_VERSION_ATOM],
- [m4_define([$1], m4_bpatsubst(m4_bregexp(LU_VERSION_H,
- [^#define *$1 *\(.*\)
-],[\1]),
-dnl The m4_bregexp() that ends above will return the end of the line that
-dnl contains the #define which was named in the first macro parameter.
-[\( \|/\*.*\*/\|//.*\)*$],))])
-dnl m4_patsubst() then strips all trailing whitespace and comments, and
-dnl finally m4_define() defines the name for use in AC_INIT().
+ [m4_define([$1], m4_bregexp(LU_VERSION_H,
+ [^#define\s*$1\s*\([0-9]*\).*], [\1]))])
+dnl The m4_bregexp() returns (only) the numbers following the #define named
+dnl in the first macro parameter. m4_define() then defines the name for use
+dnl in AC_INIT().


//Peter

[Pete Batard]

Post by Peter Stuge
Yes principle looks good and it works. The following should still

It does, as well as on MinGW. Also, -stuge looks good to me for cygwin,
if you want to go release with that.

Regards,

/Pete

[Peter Stuge]

Post by Pete Batard

Post by Peter Stuge
Yes principle looks good and it works. The following should still

It does, as well as on MinGW. Also, -stuge looks good to me for cygwin,

Great!

Post by Pete Batard
if you want to go release with that.

Let's see how much we can get done. I'm looking at the nano now. Do
you want it also in the string, or is it enough to have it in
FILEVERSION and PRODUCTVERSION?


//Peter

[Pete Batard]

Post by Peter Stuge
Let's see how much we can get done.

OK.

Post by Peter Stuge
I'm looking at the nano now. Do
you want it also in the string, or is it enough to have it in
FILEVERSION and PRODUCTVERSION?

Need it in the string, since that's what you see when you right clcik on
the DLL in explorer and check the properties.

Here's the .rc and version.h I'm working with ATM. There was a
"libusb-1" instead of a "libusb-1.0" in your .rc which I fixed.

Also, one thing I just found out is that (cywgin's) autoconf can only
handle a single line comment at the top of version.h with the
m4_define([LU_VERSION_H], m4_include([libusb/version.h])) statement. If
you try multiline comment, or another comment somewhere in the file, you
get:

/usr/bin/m4:configure.ac:2: Warning: excess arguments to builtin
`m4_define' ignored

Therefore, I'm unable to state what the nano is meant for in
version.h... Attached is what I plan to use. I'll produce a patch
against stuge when I'm done modifying -pbatard.

Regards,

/Pete

[Pete Batard]

Post by Pete Batard
There was a
"libusb-1" instead of a "libusb-1.0" in your .rc which I fixed.

Disregard, was looking at the wrong file.

/Pete

[Peter Stuge]

Post by Pete Batard
Need it in the string, since that's what you see when you right
clcik on the DLL in explorer and check the properties.

Ok. How about only including the nano in the string if > 0?

Post by Pete Batard
Also, one thing I just found out is that (cywgin's) autoconf can only
handle a single line comment at the top of version.h with the
m4_define([LU_VERSION_H], m4_include([libusb/version.h])) statement.

Maybe you have a comma in the comment? Since the literal contents of
the file is put into the define and used later as macro parameter,
there can't be commas in there or they will make it look like there
are extra parameters. I played with the m4 for a while trying to make
it more robust, but figured it was just easier to pay attention when
version.h changes.

Post by Pete Batard
Attached is what I plan to use. I'll produce a patch against stuge
when I'm done modifying -pbatard.

I'm simply adding the changes to the commit I have, so save that
effort.


//Peter

[Pete Batard]

Post by Pete Batard
Need it in the string, since that's what you see when you right
clcik on the DLL in explorer and check the properties.

Ok. How about only including the nano in the string if> 0?

That can be done.

The thing is, whatever you do, MS will use both the FILEVERSION macro,
which expects a nano, and the string to generate version details (go
figure why), so you will end up with:

File version 1.0.8.0
Product version 1.0.8

When checking the DLL properties.

Might as well have the same for both, and that implies using the nano on
the string, even if 0.

Post by Pete Batard
Also, one thing I just found out is that (cywgin's) autoconf can only
handle a single line comment at the top of version.h with the
m4_define([LU_VERSION_H], m4_include([libusb/version.h])) statement.

Maybe you have a comma in the comment?

Damn, that's the issue exactly.

If you want, you can add the following comment before the NANO def:

/* The nano may be used for Windows internal versioning. If you don't
use it keep 0 */

Regards,

/Pete

[Pete Batard]

Post by Peter Stuge
ac9ed9d add gitattributes
Added, but only for the files that actually exist. Ie. *.sh *.ac *.am
The commit that adds the other files should also add the entries to
.gitattributes.

Actually there was a purpose in doing that before the files themselves
are added.

Can you confirm that when modifying .gitattributes along with adding a
new file referenced in .gitattributes, git will take into account the
attributes before doing anything else?

I suspect that is the case, but I've grown cautious about line
terminator handling, and I'd hate to have LF project files that need to
be converted.

That's why, to be 100% safe, the MS project file .gitattributes stuff
was anticipatory.

Regards,

/Pete

[Pete Batard]

Just putting a note there for manual .def generation.

If you have a MinGW32 generated DLL, the following should generate the
expected .def:

$ echo -e "LIBRARY\nEXPORTS" > libusb-1.0.def; strings libusb-1.0.dll |
grep libusb | grep @ | sort | sed -e "s/\(.*\)@\([0-9]*\)/ \1\n \1@\2
= \1/" >> libusb-1.0.def

Regards,

/Pete

[Pete Batard]

Common stuff used by all subsequent MS projects. To be applied ontop of
-stuge.

.gitattributes modification is also done there to be safe.

Regards,

/Pete

[Peter Stuge]

+++ b/.gitattributes
@@ -1,3 +1,7 @@
-*.sh eol=lf
-*.ac eol=lf
-*.am eol=lf
+*.sh eol=lf
+*.ac eol=lf
+*.am eol=lf
+*.dsw eol=crlf
+*.dsp eol=crlf
+*.sln eol=crlf
+*.vcxproj* eol=crlf

I added the new lines with just one space after the glob. Also, since
the *.dsp files are generated with a trailing whitespace on empty
!MESSAGE lines and on !ENDIF lines I added whitespace=space-before-tab
so that trailing whitespace will not be warned on. (Default is to
follow core.whitespace, which defaults to trailing-space+space-before-tab)


//Peter

[Pete Batard]

Post by Peter Stuge
I added the new lines with just one space after the glob. Also, since
the *.dsp files are generated with a trailing whitespace on empty
!MESSAGE lines and on !ENDIF lines I added whitespace=space-before-tab
so that trailing whitespace will not be warned on.

Good call. Thanks!

/Pete

[Pete Batard]

[Pete Batard]

[Peter Stuge]

Some very minor things and a possible problem.

+++ b/msvc/ddk_build.cmd
@@ -0,0 +1,106 @@

I trimmed the trailing whitespace on this line.

+set dstPath=%destType%\Debug
+if %DDKBUILDENV%==chk goto isDebug
+set dstPath=%destType%\Release
+:isDebug

You probably know that set can be rolled into the if, but it would
need negating the condition.

+if exist %destType% goto md2
+mkdir %destType%
+:md2

Same with mkdir. And somewhere MS recommends checking \NUL to know
that it's a directory. Ie.

if not exist %destType%\NUL mkdir %destType%

+:usage
+echo ddk_build must be run in a WDK build environment
+pause
+goto done
+
+:done
\ No newline at end of file

I added the newline. Another note is that :eof is a built-in implicit
label in CMD on XP and later, which works exactly like the explicit
:done.

+++ b/msvc/libusb_sources

..

+SOURCES=..\core.c \
+ ..\descriptor.c \
+ ..\io.c \
+ ..\sync.c \
+ threads_windows.c \
+ poll_windows.c \
+ windows_usb.c \
+ libusb-1.0.rc

Does libusb-1.0.rc also need ..\ here?


//Peter

[Pete Batard]

Post by Peter Stuge
You probably know that set can be rolled into the if, but it would
need negating the condition.

Yeah. And I also know I wasn't the one who created that script, and that
microoptimization has been frowned on on this list lately.
Are you saying it's not OK microoptimizing our code with calloc or
hashing, but it's worth microoptimizing a batch? Just sayin'...

Post by Peter Stuge
Same with mkdir. And somewhere MS recommends checking \NUL to know
that it's a directory. Ie.
if not exist %destType%\NUL mkdir %destType%

OK, that's good to know.

Post by Peter Stuge
I added the newline. Another note is that :eof is a built-in implicit
label in CMD on XP and later, which works exactly like the explicit
:done.

OK.

Post by Peter Stuge

+ libusb-1.0.rc

Does libusb-1.0.rc also need ..\ here?

Doesn't seem to matter one bit to DDK (it'll still pick the file from
..\ - works for sources as well, though you'll get a warning then), but
you're right, a ..\ should be added.

Regards,

/Pete

[Pete Batard]

[Ludovic Rousseau]

Post by Peter Stuge

Post by Xiaofan Chen
we may choose to fork libusb-1.0, actually fork from
libusb-pbatard branch.

This is not really a "may", this has been reality for a long time
already, and it is unfortunate because it detracts from libusb.git,
meaning that what does get released has received less testing than it
could have.

Yes. And creating a libusb-stuge.git without merging it (often) in
libusb.git is part of the problem.

Post by Peter Stuge
To some degree the next released version will help change this, but I
think it depends more on what we recommend people to use.
In the end this situation can change only when -pbatard.git has been
aligned onto libusb.git, and all development continues based on
libusb.git and nothing else.

Post by Xiaofan Chen
the current situation is not healthy to move libusb-1.0 forward.

I think I got the co-maintainer confidence in part because I am
thorough and have attention to detail. That could of course also be
misunderstood as nothing but slow. I think that since it has taken a
while from .8 to .9 it's more important to try our best to make .9
really good. But that could be wrong of course.

The 1.0.9 version do not need to be "really good". This version first
need to BE.
New bugs/issues can be fixed in a 1.0.10 version.

Peter, I do no know your background. Maybe you are a hardware guy.
libusb is not a hardware project. It does not need to be perfect
before going into production. "We" can make a new release every day if
needed. The cost of a new release is minimal. The cost of no release
is (very) high.


I agree with Xiaofan that the solution may be to fork the libusb project.
The two admins of the libusb sourceforge project [1] are Daniel Drake
and Johannes Erdfelt.
According to my libusb-devel archives, the latest mail from Daniel
Drake is from 21 November 2008. So we should not count on Daniel as a
release maintainer.
The latest mail from Johannes Erdfelt was 29 January 2010. Johannes
are you still there?

Sourceforge has a documentation about Abandoned Project Takeover [2].
I would not like to go this way, but if everything else fails...

Regards,

[1] http://sourceforge.net/projects/libusb/develop
[2] http://sourceforge.net/apps/trac/sourceforge/wiki/Abandoned%20Project%20Takeovers

[Xiaofan Chen]

On Fri, Apr 15, 2011 at 8:37 PM, Ludovic Rousseau

Post by Ludovic Rousseau

Post by Peter Stuge

the current situation is not healthy to move libusb-1.0 forward.

I think I got the co-maintainer confidence in part because I am
thorough and have attention to detail. That could of course also be
misunderstood as nothing but slow. I think that since it has taken a
while from .8 to .9 it's more important to try our best to make .9
really good. But that could be wrong of course.

The 1.0.9 version do not need to be "really good". This version first
need to BE.
New bugs/issues can be fixed in a 1.0.10 version.

Agreed!

Post by Ludovic Rousseau
Peter, I do no know your background. Maybe you are a hardware guy.
libusb is not a hardware project. It does not need to be perfect
before going into production. "We" can make a new release every day if
needed. The cost of a new release is minimal. The cost of no release
is (very) high.
I agree with Xiaofan that the solution may be to fork the libusb project.
The two admins of the libusb sourceforge project [1] are Daniel Drake
and Johannes Erdfelt.
According to my libusb-devel archives, the latest mail from Daniel
Drake is from 21 November 2008. So we should not count on Daniel as a
release maintainer.

It is actually 29 September 2010 as per my archive (Gmail). It is also
here in Nabble.
http://libusb.6.n5.nabble.com/PATCH-WIN-5-8-added-xusb-example-td2265689.html#a2895965

Post by Ludovic Rousseau
The latest mail from Johannes Erdfelt was 29 January 2010. Johannes
are you still there?

Not so sure. But he is the original developer of libusb and pass the
maintainership to Daniel Drake back in January 2008. Later he
added Peter Stuge as the co-maintainer.
http://www.libusb.org/

Anyway, the above is just history and we need to move forward.

Post by Ludovic Rousseau
Sourceforge has a documentation about Abandoned Project Takeover [2].
I would not like to go this way, but if everything else fails...

It is not really abondoned but just moving too slow after Peter took over.
Actually during Daniel's rein, it was released quite often.
http://sourceforge.net/projects/libusb/files/libusb-1.0/

[Michael Plante]

Post by Pete Batard
Now, the way I would have preferred to proceed with HID removal was
removing it from -pbatard first (which I am going to do next), so that
I have some idea of how it will impact features that are missing from
mainline, and then remove it from mainline.

I recommend that Peter should delay pushing that commit to libusb.git until
you've had a chance to do this.

I guess one bright side is maybe, without HID, xusb will be simple enough to
keep as-is?

Regards,
Michael

[Michael Plante]

Post by Xiaofan Chen
It is actually 29 September 2010 as per my archive (Gmail).

I have one a couple days later, not that it matters much: 4 October 2010:

http://libusb.6.n5.nabble.com/PATCH-libusb-populate-the-pc-Libs-private-fiel
d-td2641782.html


Regards,
Michael

[Michael Plante]

Post by Peter Stuge
234ff93 add MSVC/WDK project files
Please make the .def have only one alias for each function; the one
that matches the size of parameters.

Would it be acceptable for this to be manually generated/updated? I don't
remember whether an automatic procedure for actually extracting this
information was ever described, but maybe I've forgotten.

Michael

[Peter Stuge]

Post by Michael Plante

Post by Peter Stuge
234ff93 add MSVC/WDK project files
Please make the .def have only one alias for each function; the
one that matches the size of parameters.

Would it be acceptable for this to be manually generated/updated?

I think it's fine for now, we can help each other remember updates.

Post by Michael Plante
I don't remember whether an automatic procedure for actually
extracting this information was ever described, but maybe I've
forgotten.

I don't know if anyone researched it but me, and I know I didn't
submit a patch that would do it, but I believe there are at least two
ways to do automatic generation. (One text based, one binary.) Both
need some tools of course.


//Peter

[Pete Batard]

Post by Peter Stuge

Post by Michael Plante

Post by Peter Stuge
234ff93 add MSVC/WDK project files
Please make the .def have only one alias for each function; the
one that matches the size of parameters.

Would it be acceptable for this to be manually generated/updated?

I think it's fine for now, we can help each other remember updates.

Sure hope it is, so that's what I plan to do, unless you want to add
more delay on the release.

Post by Peter Stuge

Post by Michael Plante
I don't remember whether an automatic procedure for actually
extracting this information was ever described, but maybe I've
forgotten.

I don't know if anyone researched it but me,

I did, but not extensively after I realized that the one automatic
procedure to generate the .def I currently use was a 15 mins job and its
only drawback really was to add dead weight to the .def/import libs.

Post by Peter Stuge
and I know I didn't
submit a patch that would do it, but I believe there are at least two
ways to do automatic generation. (One text based, one binary.) Both
need some tools of course.

Yeah, that's the conclusion I got to. The binary one might prove more
problematic for libusb maintainers as it'd require some form of
compilation (or use of a compilation helper tool). The text approach
would probably be best in that respect, since at least on Windows, one
wouldn't have to first use compiler tools to generate a file used to
produce a .def, and then recompile a second time with the resulting
.def. However, it's likely to be more complex to do right, and in a
generic fashion, as there's only so much sed can do with parsing a file
in a fashion that can be maintained easily.

This is why I concluded that the job of doing a nicer automation of the
.def generation, that removes all the dead weight, was probably better
left for when we have nothing better to do.

Regards,

/Pete