On 2010.09.04 19:22, Peter Stuge wrote:
> Yep. It was a while since I talked to them and things have likely
> improved, but still I don't see a point in encouraging use of
Convenience, future-proof and getting in line to what occurs in other
development environments. Here, 3 points.
>> given the current rate of integration of patches into libusb, it's
>> become quite difficult to want to focus on libusb problems,
> I still believe that the rate of integration is a function of patch
> mergeability. High mergeability = no-op to merge, low = rework
> "processing" needed.
No it isn't. One of the issues is that Daniel is not actively
participating in our discussions, which I find very damaging for the
project, so when a patch like __declspec(dllexport) / def files comes
into his view, the first question he asks is "why don't you guys do it
this way instead?" and we have to recap what's been discussed before and
why we ended up with the solution that was submitted as a patch. This
occured a few times already. What would actually help with high
mergeability is if the maintainer was actively involved in the decisions
that result in the patch he'll have to review eventually. Unfortunately,
this is not happening.
> (As an example, hotplug could be worked on in one branch, and a
> libusb0.sys backend in another, without significant overlap.)
Well, hotplug is (was?) actually being worked on in one branch by Daniel
 but it's been months now and nothing has happened. And now we have
the Nokia patch. So what's our line here? Do we try to use the Nokia
approach? Do we use Daniel's unfinished work? Do we take another
approach? And who shall do the work on the Linux hotplug? When can we
expect it? Also what does Daniel think about the geolocation feature we
discussed previously? ...which brings us to:
>> Unfortunately, [Daniel] seems to be very busy, and libusb doesn't
>> seem to be his main priority.
> I think this is true for all of us.
I'm talking about his priority outside of whatever he's being paid for
to do. I'm hoping that he has a reasonable amount of spare time to spend
on open source, especially as he has taken the role of libusb project
lead, and I would like our lead to be actively involved in the project
then. Of course, I don't know his precise circumstances, but I can
compare with how other project leads seem to be involved in their
respective FOSS projects, and what I'm seeing here doesn't fill me with
confidence, so, rather than skirt around, I'm telling it straight.
>> As a result, I fear that people are going to start losing
>> confidence in the libusb project as a whole if this goes on for
>> much longer.
> You're free to fear, but why spread it around? Personally I consider
> this to be derogatory for no apparent reason.
Yes, let's ignore that we have an obvious problem, that'll make it go
away... However I look at it, I don't think Daniel is involved enough in
libusb, as it takes him weeks to process patches. Not to say that he
might actually have a choice in the matter. But if anything, when a
company like Nokia submits a large patch, I'd expect the project
maintainer to comment on it, even if it's to say "Thanks, but that won't
do, *because this is how we are planning to do it*". That's what I'd
expect to happen on any other open source project, and the fact that it
doesn't happen here is disturbing, at least with regards to my
expectations of how FOSS development should occur in a healthy environment.
> The last release has few if any major bugs and coming releases will
> have improvements. This is all one can ask for IMHO. It's open source
> software; if the shoe does not fit then you get to fix it. :)
Except people are clearly not satisfied with our bug-free releases and
*ARE* asking for more features (hotplug, geolocation, log timestamps,
etc.). If libusb is to be considered a frozen project, then let's flag
it as such. Then someone can fork it, add new features in a reasonable
timeframe (the features listed above really shouldn't take that long to
implement if people dedicate some time), and everybody's clear where we
stand. It's not because it's open source that we should not strive to
get work done in a reasonable amount of time.
>> Is there anything that could be done to address this situation and
>> make sure active development is fostered in libusb 1.0?
> I don't agree that active development is really blocked. I'm happy
> to set up repositories and work can go on even if some things will
> need to be reworked before entering libusb.git if there's inadequate
Creating branches is not the answer. Patches will still need to be
submitted for integration in official, and if weeks go by before Daniel
reviews them, not much will be gained from using separate branches.
Plus, people have already been officially complaining about our rate of
> If you're saying that intense communication, training and guidance
> would be nice, then I agree
Guidance from Daniel is required. It's not a nice to have feature: any
project needs an active leader, else we end up with ad nauseam
discussions because we can't figure out what the the maintainer will
eventually want (eg: CJK libtool patch, declspec vs .def, calling
> but I also have to point out that there
> are simply no such resources available, and reading the license there
> is of course also no promise of such resources being available.
This seems to happen on most with the other open source projects I know.
Most other open source project leaders seem to be actively involved in
the mailing list for that project and in discussing new developments.
Ours isn't, ergo we have a problem.
> That doesn't make the project any less useful IMO, and I certainly
> don't believe that it would make people lose any confidence they
> might have in libusb.
Well, I'm looking at the list of opened issues  and I'm not seeing
much happening. If I was interested in using libusb for an application,
that's the first place I'd be looking out to see how active the project
is. I'd also probably try to see what's the turnover rate for patches
submitted on the mailing list. Not sure the libusb results would feel me
with great confidence...
Therefore, I do believe we have a problem, and we should try to see what
can be done to address that problem.